Confirmed here on Mageia 5 beta1.

CC: (none) => remi
Whiteboard: (none) => 5beta1

Setting it as release_blocker (for Mageia 5, not necessarily for Beta1, but hopefully we'll get this fixed before Beta2).

Priority: Normal => release_blocker

confimed also after an upgrade of Mga4 to Mga5

CC: (none) => makowski.mageia

and now I have the problem on another box that was yet under Cauldron, so it is not an install bug but a Gnome or gdm one.

(In reply to Philippe Makowski from comment #4)
> and now I have the problem on another box that was yet under Cauldron, so it
> is not an install bug but a Gnome or gdm one.

indeed, so it is valid  (just seeing it on 32bits Gnome Live DVD) for the Live Gnome isos, too

CC: (none) => marja11

mentioning it here, no time to file or look for a seperate bug report (and it might be the same underlaying bug, anyway):

With the Gnome Live DVD, if you set everything to Dutch / Amsterdam / the Netherlands, the screens before reaching Gnome are all in Dutch.

However, Gnome is in English and the locale command (when given in a terminal inside Gnome) shows all settings are en_US

OK, again with the Gnome Live 32bits DVD:
when in a Gnome terminal, the output of "locale" is "en_US" for every item
when on tty3, the output of the same "locale" is "nl_NL" for every item

:-(

After a classical 64 bits install, only the keyboard issue exists in Gnome, but the "locale" output is exactly what it should be, so whatever causes the issue mentioned in comment 6 and 7, it must be something different

my last tests : the keyboard issue is in gdm only
what is strange is that all is in French, but keyboard have US layout and this only in gdm, under Gnome and Cinnamon, my keyboard layout is French

Olav any ideas ? something upstream ?

CC: (none) => olav

I confirm this bug.
Fresh install of beta1 (with gnome DM) and French setting. At the first boot, gdm and gnome are layout qwerty. If I add a french keyboard layout in the gnome config panel then it's work.

CC: (none) => axonefr

Related, or the same bug: I use US International layout in the nl_NL locale to be able to type accents with AltGr (right Alt). I don't see a way to configure this any more under current Cauldron with Gnome, not even with gnome-tweak-tool. Am I overlooking something?

CC: (none) => reinout

My Cauldron is installed from a classical 64 bits, with locale in french.
(on 2 computers) 
Kde4 work all in french, with keybord  AZERTY.

But Gnome is all in locale en , with keybord qwerty .
Gnome config accept french locale, ...but keybord canot do azerty mode.
Command loadkeys fr  do nothing !

CC: (none) => christian-maryse.fischer

Olav, no ideas ?

hello
User command: setxkbmap fr  get azerty mode.

Olivier hit this bug with the pre-5beta2 LiveDVD

Whiteboard: 5beta1 => 5beta2
CC: (none) => olchal

Olav, any input please ?

CC: (none) => ennael1

may be this link can help :
http://archlinux.2023198.n4.nabble.com/GDM-td4702089.html

Also noticed in gnome installed from classic 5beta2 DVD 32. 

US keyboard despite installing as en_GB.

Gnome settings => Region & Language settings shows it has Language - English(United States) and Formats - United States. 

So l10n is being completely ignored.

Correct l10n for both settings is available in gnome settings, just not being used.

This is valid in 4th round (january 10th) gnome live isos. At least livedvds anyway.

Wasn't this fixed in a previous build?

CC: (none) => tmb

GNOME uses freedesktop.org / systemd way of doing things. The installer AFAIK uses a different method. If you configure within GNOME it does the right thing. Installer should use the right way to set this, but don't have details on what this requires.

Colin would know.

CC: (none) => mageia

The installer should (AFAIK) write the correct vconsole.conf file, but it might not add a dropin file (that systemd manipulates) into /etc/X11/xorg.conf.d/00-keyboard.conf (which is a file manipulated by localed to provide the systemd services).

That said, in the past gnome always inherited what was in the environment so what the installer wrote still worked fine even without these files, so I'll have to look into things again to see what broke.

I did want to kill off our own ways of doing things and only use nice interfaces provided by systemd by up until fairly recently this is really problematic in an installer context. We really want to "boot" the installed system and then poke at various services (namely localed and timedated) to set the various values on the installed system. Anyway, one day it'll be much less hacked together and we can clean up the whole of the xinit mess (that is part ours and part "how things are done") once we move over to the systemd --user handled session fully (been doing experiments in this area recently but it's a lot of work and certainly won't be ready for this release - but I digress)

FWIW, in the past it was found the various env vars were ignored or not processed/exported properly.

IIRC I remember some GDM_LANG vars getting nuked and no longer supported upstream so it could be due to this. It's probably easier just to tweak the installer to write the X11 keyboard file as per above even if it's a bit ugly to do it outside of the localed daemon.

Will add it to my list.

It's valid for both classic isos and live isos so draklive-install also.

I didn't notice live mode, but will check now.

It's the same in live mode.

Maybe https://bugzilla.gnome.org/show_bug.cgi?id=730478

Nothe that we also need to handle upgrade path, as currently a upgrade with urpmi gets us into the same trouble

@colin: see https://bugs.mageia.org/show_bug.cgi?id=14613 for the installer or localedrake missing to write /etc/locale.conf - maybe this would already be enough to also fix this bug too.

CC: (none) => doktor5000

I know your todo list is huge Colin, but would you manage to have a look at this soon? I think most GNOME/GDM/localisation/keyboard layout bugs (at least 3 or 4 of our current release_blockers) might be related to what you described in comment 24.

commit 2969bde783d7e815a9867fe323e17394369579aa
Author: Colin Guthrie <colin@...>
Date:   Sun Feb 8 21:17:53 2015 +0000

    users: Make sure to restart accounts-daemon after adding users (mga#15113)
    
    This prevents various details being loaded about the user when they first
    login (including being listed in GDM and other user editing bits within
    GNOME).
    
    It also has some effect on i18n where the user's language settings are
    totally reset (to en_US) rather than inheriting the system prefs
    which seems to be the problem presented in mga#14476
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=2969bde783d7e815a9867fe323e17394369579aa

 Bug links:
   Mageia
      https://bugs.mageia.org/15113
      https://bugs.mageia.org/14476

OK, so I found that if I didn't restart accounts-daemon after creating the user in live mode, the locale settings were set to en_US, not en_GB (which is my system setting). It seems that not getting the user from accounts service is somewhat fatal to GNOME and it reverts to en_US.

The above seemed to fix it for me.

I think the above should fix this issue for live and various other fixes in drakx today will write appropriate config files (locale.conf and vconsole.conf) to make GDM/GNOME pick them up.

Testing Mageia5B3 round 3 x64  gnome live DVD on real hardware.

Setting French and azerty at boot :
- in live mode : French localization and azerty keyboard OK
- installing from live mode : 
   . on first reboot, after giving name user and password, gdm-session failed (oops, something has gone wrong...)
   . on second reboot, could log into gnome shell (automatic login set by installer), french localisation and azerty keyboard correctly set.

On this installation, apart from the failure on first reboot which may not be related, this fix resolved present bug for me.

Congrats.

Testing Mageia-5-beta3-KDE4-LiveDVD-x86_64 round3 (vbox in live mode)

Setting French localization and azerty keyboard:
- KDE fails to use the right keyboard layout, keyboard is qwerty.
     setxkbmap fr get azerty
  This was working fine previously with round 2 for KDE Live.

- if I logout from the first session, and return to kdm
  + kdm uses the good layout, azerty
  + login with Live user, KDE uses the right keyboard layout, keyboard is azerty.


It was too late yesterday evening to do more debug, try an install, ... , but perhaps /etc/sysconfig/i18n and/or /etc/locale.conf are written too late to be used by kdm in the first session (autologin) ???

CC: (none) => lmenut

(In reply to Luc Menut from comment #35)
> Testing Mageia-5-beta3-KDE4-LiveDVD-x86_64 round3 (vbox in live mode)
> 
> Setting French localization and azerty keyboard:
> - KDE fails to use the right keyboard layout, keyboard is qwerty.
>      setxkbmap fr get azerty
>   This was working fine previously with round 2 for KDE Live.

Dammit! I have whack-a-mole! Just to confirm, this is just a keyboard problem, not UI language (it's still correctly in French?)

> - if I logout from the first session, and return to kdm
>   + kdm uses the good layout, azerty
>   + login with Live user, KDE uses the right keyboard layout, keyboard is
> azerty.
> 
> 
> It was too late yesterday evening to do more debug, try an install, ... ,
> but perhaps /etc/sysconfig/i18n and/or /etc/locale.conf are written too late
> to be used by kdm in the first session (autologin) ???

So, these files are only used for language, not keyboard layout.

/etc/sysconfig/keyboard and /etc/vconsole.conf are used for keyboard stuff.

But the only changes I made in relation to that was to write to /etc/vconsole.conf *as well as* /etc/sysconfig/keyboard and to write out a /etc/X11/xorg.conf.d/00-keyboard.conf file. I didn't change any other keyboard handling stuff :s

In the case of KDE, the latter is likely not even read as X is not restarted. I wonder if the write method somehow aborted? I don't think so. Can you check that you got a /etc/X11/xorg.conf.d/00-keyboard.conf file and it looks sensible?

Although, I did just spot a typo... grrr. It shouldn't be to blame tho', as technically it's in a bit of code that should never actually crop up really.

It would also be interesting to know if running "mageia-setup-keyboard" (as root) after logged in somehow magically set the correct keymap.

This should trigger a udev change and load the correct properties against the keyboard that the X11 stuff should read in.

I'm not sure if this happens dynamically in xorg (e.g. if the input driver detects a "new" keyboard and re-reads the properties of it from udev) or not.

Note that mageia-setup-keyboard is really a custom hack. We should probably drop it in favour of the xorg.conf snippet which we now write, but I'm not sure what happens at runtime for keyboard selection... I'm not convinced this gives us anything better.

(In reply to Colin Guthrie from comment #36)

I'm at work, and reply from memory, so ...
I don't have these .iso here, I will check tonight at home.

> (In reply to Luc Menut from comment #35)
> > Testing Mageia-5-beta3-KDE4-LiveDVD-x86_64 round3 (vbox in live mode)
> > 
> > Setting French localization and azerty keyboard:
> > - KDE fails to use the right keyboard layout, keyboard is qwerty.
> >      setxkbmap fr get azerty
> >   This was working fine previously with round 2 for KDE Live.
> 
> Dammit! I have whack-a-mole! Just to confirm, this is just a keyboard
> problem, not UI language (it's still correctly in French?)

yes, IIRC UI language was in French.

> 
> > - if I logout from the first session, and return to kdm
> >   + kdm uses the good layout, azerty
> >   + login with Live user, KDE uses the right keyboard layout, keyboard is
> > azerty.
> > 
> > 
> > It was too late yesterday evening to do more debug, try an install, ... ,
> > but perhaps /etc/sysconfig/i18n and/or /etc/locale.conf are written too late
> > to be used by kdm in the first session (autologin) ???
> 
> So, these files are only used for language, not keyboard layout.
> 
> /etc/sysconfig/keyboard and /etc/vconsole.conf are used for keyboard stuff.

IIRC virtual console was in azerty (OK).

> 
> But the only changes I made in relation to that was to write to
> /etc/vconsole.conf *as well as* /etc/sysconfig/keyboard and to write out a
> /etc/X11/xorg.conf.d/00-keyboard.conf file. I didn't change any other
> keyboard handling stuff :s
> 
> In the case of KDE, the latter is likely not even read as X is not
> restarted. I wonder if the write method somehow aborted? I don't think so.
> Can you check that you got a /etc/X11/xorg.conf.d/00-keyboard.conf file and
> it looks sensible?

I will check tonight.

> 
> Although, I did just spot a typo... grrr. It shouldn't be to blame tho', as
> technically it's in a bit of code that should never actually crop up really.

Testing on Mageia 4x64 classic DVD x64 bits UEFI GNOME install on real hardware

Setting French localization + azerty keyboard during installation :

Gnome desktop boots ok, french localization and azerty keyboard correctly set.

(In reply to Luc Menut from comment #35)
> Testing Mageia-5-beta3-KDE4-LiveDVD-x86_64 round3 (vbox in live mode)
Same test.
> 
> Setting French localization and azerty keyboard:
> - KDE fails to use the right keyboard layout, keyboard is qwerty.
>      setxkbmap fr get azerty
>   This was working fine previously with round 2 for KDE Live.
> 
> - if I logout from the first session, and return to kdm
>   + kdm uses the good layout, azerty
>   + login with Live user, KDE uses the right keyboard layout, keyboard is
> azerty.

I confirm the same bug with French localization and keyboard (qwertz).
The virtual consoles use the German keyboard layout too. When logging off, KDM uses the good layout too.
=> Everything as Luc described it, so the bug is reproducible.

Booting the same live DVD directly to the installer (i.e. not in live mode) also shows additional localisation regressions: after the language selection, the content is properly localised up to the advertising screen just before the partitioning step. Afterwards, everything is in English.

Maybe we should open a new bug report for those i18n regressions?

Re comment 41: the installed system is in French, with the proper keyboard layout too from scratch. So it seems that what the live mode and live installer are relying on to determine the locale and keyboard setting is broken.

Replicated here on KDE4 live too.

Some more info from tests:

1. Running mageia-setup-keyboard does trigger udev event and does make xorg re-process the keyboard.
2. The correct keyboard layout is properly set as a udev property (according to udevadm info: so this has been correctly set during the initial configuration and injected via mageia-setup-keyboard).
3. Although xorg sees the keyboard event from udev and re-processes it, it *doesn't* see the language (Xorg.0.log says xkb_layout us.)

So *something* has changed, but I really don't see how it could have been my changes... I'm confused! Did xorg change in the last build of the ISOs?

Hmm, yes! 

http://svnweb.mageia.org/packages/cauldron/x11-server/current/SOURCES/0104-config-udev-Respect-seat-assignments-when-assigned-d.patch?view=markup 

this changes udev hotplug behaviour which is exactly the bits that are used here... not saying this is to blame, but it's certainly in the right path...

Will study it more deeply later.

Yeah, It seemed like a good change and is from upstream 1.16 stable branch...
And fedora also pushed this fix to their stable release...


But I wonder if we should simply revert it for now to get beta3 out and even maybe keep it out of whole mga5 release... then revisit the xorg autoconf/autoload support for mga6

/etc/X11/xorg.conf.d/00-keyboard.conf seems fine
cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "fr"
        Option "XkbModel" "pc105"
        Option "XkbOptions" "compose:rwin"
EndSection


Could it help to restart the dm just after config like for Gnome Live ?

Just to be clear,  I'm not certain it's the Xorg patch (and I agree it looks sensible!) but it does fit the bill (as much as my other changes!) 

And yeah, restarting the DM is a good backup plan if all else fails!

Hmm, I just tried hacking in a french layout to my sysconfig file here and re-ran mageia-setup-keyboard. I'm running the older xorg still (started last sunday, xorg package updated/installed on monday, so I should still be running the old code).

Anyway, even although udev properties were updated, xorg didn't seem to read them properly :(

I think the patch I pointed to last night is therefore a red herring.

What I'm really not sure about is why xorg is just not seeing the new properties from udev.... It's like there is some kind of cache in libudev and it's not seeing the new values from udev db itself.... I don't see how this could be new tho'. (there is a new systemd version, but only a few patches in there... /me looks more closely)

Hi,

OK, I've found the problem

It's definitely my changes, not this patch!

If you boot to runlevel 3 before starting X you see that the /etc/X11/xorg.conf.d/00-keyboard.conf is already written, so something that triggers at early boot sets this up first and writes it with us layout.

The hard coded config seems to override udev properties. Not sure why this doesn't affect GNOME too tho'...

(In reply to Colin Guthrie from comment #49)
> The hard coded config seems to override udev properties.

Confirmed this with some verbose logging.


[   188.523] (II) config/udev: removing device AT Translated Set 2 keyboard
[   188.523] (II) evdev: AT Translated Set 2 keyboard: Close
[   188.523] (II) UnloadModule: "evdev"
[   188.523] (II) config/udev: getting attribute name on (null) returned "AT Translated Set 2 keyboard"
[   188.523] (II) config/udev: getting property PRODUCT on (null) returned "11/1/1/ab41"
[   188.523] (II) config/udev: getting property ID_INPUT.tags on /dev/input/event0 returned "(null)"
[   188.523] (II) config/udev: getting property ID_INPUT_KEY on /dev/input/event0 returned "1"
[   188.523] (II) config/udev: getting property xkblayout on /dev/input/event0 returned "fr"
[   188.523] (II) config/udev: getting property xkbmodel on /dev/input/event0 returned "pc105"
[   188.523] (II) config/udev: getting property xkboptions on /dev/input/event0 returned "compose:rwin"
[   188.523] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event0)
[   188.523] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[   188.523] (**) AT Translated Set 2 keyboard: Applying InputClass "system-keyboard"
[   188.523] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[   188.523]    Option "XkbRules" "evdev"
[   188.523]    Option "XkbModel" "pc105"
[   188.523]    Option "XkbLayout" "us"
[   188.523]    Option "_source" "server/udev"
[   188.523]    Option "name" "AT Translated Set 2 keyboard"
[   188.523]    Option "path" "/dev/input/event0"
[   188.523]    Option "device" "/dev/input/event0"
[   188.523]    Option "major" "13"
[   188.523]    Option "minor" "64"
[   188.523]    Option "XkbOptions" "compose:rwin"
[   188.523]    Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
[   188.523]    Option "driver" "evdev"
[   188.523] (**) AT Translated Set 2 keyboard: always reports core events
[   188.523] (**) evdev: AT Translated Set 2 keyboard: Device: "/dev/input/event0"
[   188.523] (--) evdev: AT Translated Set 2 keyboard: Vendor 0x1 Product 0x1
[   188.523] (--) evdev: AT Translated Set 2 keyboard: Found keys
[   188.523] (II) evdev: AT Translated Set 2 keyboard: Configuring as keyboard
[   188.523] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
[   188.523] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 9)
[   188.523] (**) Option "xkb_rules" "evdev"
[   188.523] (**) Option "xkb_model" "pc105"
[   188.523] (**) Option "xkb_layout" "us"
[   188.523] (**) Option "xkb_options" "compose:rwin"
[   188.523] (II) XKB: Reusing cached keymap



> Not sure why this doesn't affect GNOME too tho'...

Because we've been restarting the X server with GNOME, so that one is OK as it picks up the new config file and all is well.


Will have a think about how to solve this more fully (one option is to only write the 00-keyboard file when it a) already exists and b) we have $DISPLAY set, but that is definitely a hack!

(In reply to Colin Guthrie from comment #50)

> Will have a think about how to solve this more fully (one option is to only
> write the 00-keyboard file when it a) already exists and b) we have $DISPLAY
> set, but that is definitely a hack!

I meant a) *OR* b) above!

commit 2f39b6acb3ae70a5538b9367a60c3b2b110e8cbf
Author: Colin Guthrie <colin@...>
Date:   Wed Feb 11 10:53:36 2015 +0000

    Suppress writing xorg.conf.d snippets for built in evdev defaults
    
    This should allow us to keep a cleaner xorg.conf.d snippet when
    generated at boot without specific configuration which should then
    allow udev rules to override it without any problem.
    
    Note: we default to a pc105 layout but evdev defaults to a pc104
    layout. We should either adopt pc104, or adapt evdev to default to
    pc105.
    
    mga#14476
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/commit/?id=2f39b6acb3ae70a5538b9367a60c3b2b110e8cbf

The above change (untested) should only write the absolutely necessary bits into the xorg.conf snippet.

This is different behaviour to localed which will write out "us" even although it's the evdev default, but it should allow the necessary udev property overrides that we need.

I have tested booting kde live with the 00-keyboard.conf editited prior to x launch to remove the layout+model lines and the keymap *is* correctly set in live mode, so I know this approach should solve our immediate problem.

Have to crack on with $dayjob for now - massively behind :(

I confirm, keyboard layout is now respected. Thanks Colin.

I've just quickly tested (live mode in vbox) Mageia-5-beta3-LiveDVD-KDE4-x86_64-DVD and Mageia-5-beta3-LiveDVD-GNOME-x86_64-DVD from round 4 (Wed Feb 11 22:30:00 CET 2015) with French localization and azerty keyboard; UI localization and keyboard layout are OK.

Yay! Thanks Luc. Did some quick tests in live modes too which all seem OK in this regard. Hopefully that's this one (and a few of the other i18n ones) sorted now!

Possible failure https://bugs.mageia.org/show_bug.cgi?id=13687#c30 but may be unrelated.

The keyboard layout issue seems fixed, so closing this bug report.
Feel free to reopen if needed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

A French user reported the same problem after a upgrade 4-> 5
http://www.mageialinux-online.org/forum/topic-20365+migration-de-mageia-4-a-5-impossible-de-se-connecter-a-gnome.php

CC: (none) => yves.brungard_mageia
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Another one :
http://www.mageialinux-online.org/forum/topic-20573.php#m196862

Another one in german forums:
https://forums.mageia.org/de/viewtopic.php?f=7&t=2496

This is definitely not fixed. Happens for mga4 => mga5 upgrades, but also when I simply test a GNOME session and everything systemwide is configured to use german keyboard ( /etc/X11/xorg.conf.d/00-keyboard.conf and /etc/sysconfig/keyboard should be sufficient ) but GNOME by default only offers english keyboard mapping.

Target Milestone: --- => Mageia 6
Whiteboard: 5beta2 => MGA5TOO

Renaming the summary because the bug shows up in GDM/GNOME, but drakx didn't do things right. If distro doesn't do what GDM/GNOME expects it is not automatically the problem of GDM/GNOME! See comment 23. Also, IMO better to open new bugreports than to reopen old ones.

Summary: gdm and gnome fail to use the right keyboard layout => drakx doesn't set keyboard layout the way localed expects

(In reply to Olav Vitters from comment #61)
> If distro doesn't do what GDM/GNOME expects it is not
> automatically the problem of GDM/GNOME! See comment 23.

Sure, every other desktop environment respects the values set by drakx, and GNOME doesn't - definitely a drakx bug when all the files it should have written are present. And regarding comment 23:

(In reply to Colin Guthrie from comment #23)
> That said, in the past gnome always inherited what was in the environment

So much for reading ...

It will also help greatly to rename the bug when the localectl configuration is just fine. And creating a new bug just because the old one isn't resolved is also probably pretty helpful.


For completeness sake, just did a fresh mga5 GNOME installation, selected german locale and german keyboard. Results in:

[user@localhost ~]$ cat /etc/locale.conf 
LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8:de

[user@localhost ~]$ cat /etc/vconsole.conf 
KEYMAP=de-latin1-nodeadkeys
FONT=lat0-16

[user@localhost ~]$ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "de(nodeadkeys)"
        Option "XkbModel" "pc105"
        Option "XkbOptions" "compose:rwin"
EndSection
[user@localhost ~]$

[user@localhost ~]$ localectl 
   System Locale: LANG=de_DE.UTF-8
                  LANGUAGE=de_DE.UTF-8:de
       VC Keymap: de-latin1-nodeadkeys
      X11 Layout: de(nodeadkeys)
       X11 Model: pc105
     X11 Options: compose:rwin
[user@localhost ~]$

[user@localhost ~]$ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


Which is exactly what is expected. Guess what is not expected? GNOME uses english keyboard layout. Definitely a drakx bug then, sure ...

Even gsettings lists german as primary layout:

[user@localhost ~]$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'de(nodeadkeys)'), ('xkb', 'us')]

Summary: drakx doesn't set keyboard layout the way localed expects => gdm and gnome fail to use the right keyboard layout

(In reply to Florian Hubold from comment #62)
> Even gsettings lists german as primary layout:
> 
> [user@localhost ~]$ gsettings get org.gnome.desktop.input-sources sources
> [('xkb', 'de(nodeadkeys)'), ('xkb', 'us')]

At that point gnome settings only show english US as input source. After adding german, gsettings shows:

[user@localhost ~]$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'us'), ('xkb', 'de+nodeadkeys')]

So problem seems to be that the X11 layout is de(nodeadkeys) which gsettings shows also initally but gnome itself uses de+nodeadkeys which is why it silently discards the default layout. 

Please fix.

(In reply to Florian Hubold from comment #62)
> So much for reading ...

GNOME removed the fallback.

Thanks for the attitude. Apparently there's two issues, 2) GNOME doesn't read fallback and 2) still doesn't properly read everything.

> It will also help greatly to rename the bug when the localectl configuration
> is just fine. And creating a new bug just because the old one isn't resolved
> is also probably pretty helpful.

Yet more attitude. Though nobody mentioned localectl was fine. People tested it and it was fixed. Did you read comment 55 or just overlooked this so you can give me attitude?!? I guess you didn't right?

How the fuck do you dare to give me so much attitude?!?

> Which is exactly what is expected. Guess what is not expected? GNOME uses
> english keyboard layout. Definitely a drakx bug then, sure ...

More needless stupid fucking attitude.

(In reply to Florian Hubold from comment #63)
> Please fix.

Talking to Colin I assume? Else be prepared for me to get an earful if I see you at FOSDEM. My picture is on Planet GNOME. FOSDEM is less than a month away. Stay the fuck out of my way.

CC: olav => (none)

FWIW, I read the whole bug from top to bottom. Comment 55 only mentions it _seems_ to be fixed in live mode, and that was not with final.

(In reply to Olav Vitters from comment #64)

> Thanks for the attitude.

> Yet more attitude.

> How the fuck do you dare to give me so much attitude?!?

> More needless stupid fucking attitude.

> Stay the fuck out of my way.


All interesting comments to help solve an issue. And I'm the one showing attitude?
Get a life.

CC: doktor5000 => (none)

this bug was assigned to Colin, btw.

i'll cc pkg-bugs, though. maybe someone there has time to help

Colin, if you can't help, then please reassign to pkg-bugs ml

CC: (none) => pkg-bugs
Source RPM: (none) => -

Please consider your actions gentlemen. Thankyou.

How may we proceed?

CC: (none) => doktor5000, olav

(In reply to claire robinson from comment #67)
> How may we proceed?

If it's deemed better to open a new bug, feel free. I've tried to provide the information that might be helpful via comment 63 and comment 64. Other then that can't help much further.

CC: doktor5000 => (none)

Created attachment 8123 [details]
Suggested fix

(In reply to Florian Hubold from comment #62)
> [user@localhost ~]$ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
> # Read and parsed by systemd-localed. It's probably wise not to edit this file
> # manually too freely.
> Section "InputClass"
>         Identifier "system-keyboard"
>         MatchIsKeyboard "on"
>         Option "XkbLayout" "de(nodeadkeys)"
>         Option "XkbModel" "pc105"
>         Option "XkbOptions" "compose:rwin"
> EndSection

Although this syntax for XkbLayout is accepted by the X server, the documentation (https://www.x.org/releases/X11R7.7/doc/xorg-docs/input/XKB-Config.html) doesn't mention it, so I guess it's deprecated. The documented way of specifying a keyboard layout variant like this is:

  Option "XkbLayout"  "de"
  Option "XkbVariant" "nodeadkeys"

GNOME behaves correctly when this syntax is used. So I suggest the easiest fix for this bug is to teach the drakx tools to write the Xorg config file using this syntax. The attached patch does this.

I've tested this on a patched version of the sta1 Live GNOME DVD, and it behaves correctly when I select de/nodeadkeys and when I select gb. Clearly it needs much wider testing, and we may be a bit too close to M6 release to make a change like this now.

CC: (none) => mageia

(In reply to Martin Whitaker from comment #69)
> Created attachment 8123 [details]
> Suggested fix
> 
> (In reply to Florian Hubold from comment #62)
> > [user@localhost ~]$ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
> > # Read and parsed by systemd-localed. It's probably wise not to edit this file
> > # manually too freely.
> > Section "InputClass"
> >         Identifier "system-keyboard"
> >         MatchIsKeyboard "on"
> >         Option "XkbLayout" "de(nodeadkeys)"
> >         Option "XkbModel" "pc105"
> >         Option "XkbOptions" "compose:rwin"
> > EndSection
> 
> Although this syntax for XkbLayout is accepted by the X server, the
> documentation
> (https://www.x.org/releases/X11R7.7/doc/xorg-docs/input/XKB-Config.html)
> doesn't mention it, so I guess it's deprecated. The documented way of
> specifying a keyboard layout variant like this is:
> 
>   Option "XkbLayout"  "de"
>   Option "XkbVariant" "nodeadkeys"
> 
> GNOME behaves correctly when this syntax is used. So I suggest the easiest
> fix for this bug is to teach the drakx tools to write the Xorg config file
> using this syntax. The attached patch does this.
> 
> I've tested this on a patched version of the sta1 Live GNOME DVD, and it
> behaves correctly when I select de/nodeadkeys and when I select gb. Clearly
> it needs much wider testing, and we may be a bit too close to M6 release to
> make a change like this now.

CC'ing tv

CC: (none) => thierry.vignaud

(In reply to Marja van Waes from comment #70)
> (In reply to Martin Whitaker from comment #69)
> > Created attachment 8123 [details]
> > Suggested fix

> 
> CC'ing tv

Sorry for having said more, I can't type well on my phone.

However, thanks Martin!

I'm concerned about what this means for stage2. Does anything need to be adjusted here:
http://gitweb.mageia.org/software/drakx/tree/perl-install/install/steps_interactive.pm#n84 ?

(In case line numbers change later: that is "sub selectKeyboard")

s/having/not having/

(In reply to Marja van Waes from comment #71)
> Sorry for having said more, I can't type well on my phone.
 
Don't worry, nor can I ;-)

> However, thanks Martin!
> 
> I'm concerned about what this means for stage2. Does anything need to be
> adjusted here:
> http://gitweb.mageia.org/software/drakx/tree/perl-install/install/
> steps_interactive.pm#n84 ?

I don't think so. The changes I've made should only affect reading/writing the xorg.conf files, and that all seems to be reasonably self-contained in the modules I've changed. But as I said, this does need wider testing to be sure I've not broken anything.

As an aside, there do seem to bogus entries in the keyboards table. For example:

% setxkbmap -layout "tifinagh(phonetic)"
Error loading new keyboard description

The change looks sensible enough to me. Thierry? Not really sure why it would fail to be picked up in it's current form but better to use the documented form either way.

(In reply to Martin Whitaker from comment #73)
> But as I said, this does need wider testing

Agreed :-)

> 
> As an aside, there do seem to bogus entries in the keyboards table. For
> example:
> 
> % setxkbmap -layout "tifinagh(phonetic)"
> Error loading new keyboard description

Thanks, I opened bug 18862 for that.

ccing Pablo as he knows much about this

CC: (none) => pablo

Created attachment 8131 [details]
reworked patch to fix variants and layouts

with the « Option "XkbVariant" » syntax and a stacked multi-layout, then the exact same number of comas are needed in the XkbVariant and XkbLayout.

Which means the variant has also to grow for non latin layouts:

-    my $Layout = _keyboard2xkb($keyboard) or return { XkbDisable => '' };
+    my $Layout = _keyboard2xkbl($keyboard) or return { XkbDisable => '' };
+    my $Variant = _keyboard2xkbv($keyboard);
     if ($keyboard->{GRP_TOGGLE} && $Layout !~ /,/) {
 	$Layout = join(',', 'us', $Layout);
+ 	$Variant = join(',', '', $Variant);
     }
 
I reworked the Martin patch to add that line; and also fixed the X11 names for various layouts and variants.
There are still 4 broken keyboards (no longer on X11; they could be retrieved from an old Mandriva which still had for example a "/usr/share/X11/xkb/symbols/snd" file.
The missing ones are:
* armenian (old)  (but maybe nobody uses it? I had created it from a picture of an old (ca 1980) computer keyboard)
* Cherokee syllabics
* Dvorak (Esperanto)
* Sindhi

Attachment 8123 is obsolete: 0 => 1

Thanks a lot, Pablo :-)

commit 11c28a962a11140692fe06e046a760bc2f0e7cb3
Author: Martin Whitaker <mageia@...>
Date:   Sat Jul 9 21:35:59 2016 +0200

    Use the official X.org syntax to define keyboard layouts (mga#14476)
    o Gnome/gdm can no longer handle our unofficial or deprecated syntax
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/commit/?id=11c28a962a11140692fe06e046a760bc2f0e7cb3

commit 2315abc977903860bc7a20aff910311ad96e6435
Author: Pablo Saratxaga <pablo@...>
Date:   Sat Jul 9 22:23:47 2016 +0200

    - Improve previous patch (mga#14476)
      o with the « Option "XkbVariant" » syntax and a stacked multi-layout,
      o the exact same number of comas are needed in the XkbVariant and
      o XkbLayout
    - Fix the X11 names for various layouts and variants
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/commit/?id=2315abc977903860bc7a20aff910311ad96e6435

Can this be packaged for core/release, or should it first go into testing?

I built & tested new drakx-kbd-mouse-x11 locally, and it seems fine (changed my Dutch keyboard layout to US-international, saw it work in VT and in X, and changed it back, and noticed that at least one of the obsoleted layouts is indeed no longer listed).

However, it caught my eye that after building new drakx-installer-stage2, that according to Plasma5 Dolphin new mdkinst.sqfs is remarkably smaller than the one on the mirror.

61,8 MiB <-> 64,4 MiB

I didn't test it yet.

SRPM and 64bit mdkinst.sqfs and 64bit RPMs can be found here
http://waesvanm.home.xs4all.nl/Mageia/drakx-kbd-mouse-x11_bug14476/

mdkint.sqfs works fine here.
.
I did a Gnome install after which (with the old drakx-kbd-mouse-x11 on the mirror) gdm/gnome assumed an US keyboard. After installing the updated drakx-kbd-mouse-x11 packages and logging out, on logging in again my Dutch keyboard worked as expected.

Since no one suggested pushing drakx-kbd-mouse-x11 to testing, I'll ask a full packager to push it to core/release.

Shlomi just pushed the package to cauldron.

For Mga5 bug 18920 was opened, so the QA testers won't have to scroll down more than 84 comments.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED
Whiteboard: MGA5TOO => (none)