Bug 261954

Summary:	Updating Hal breaks keymaps
Product:	Gentoo Linux	Reporter:	Neil <nshephard>
Component:	[OLD] Core system	Assignee:	Gentoo Linux bug wranglers <bug-wranglers>
Status:	RESOLVED NEEDINFO
Severity:	normal
Priority:	High
Version:	unspecified
Hardware:	x86
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Neil 2009-03-10 08:04:23 UTC

Recently after upgrading sys-apps/hal my GB keymap has switched to US

Reproducible: Always

Steps to Reproduce:
1. Start off with a GB keymap by defining GB <merge key="input.xkb.layout" type="string">gb</merge> in /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi

2. Emerge hal
3. Reboot and you'll have a gb keymap

Actual Results:  
Keymap is now US

Expected Results:  
Keymap should remain as GB

Simply editing /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to reflect a GB layout resolves this problem, but its a bit of a pain having to do it each and everytime HAL updates.  If config files are being updated such as this, then dispatch-conf should recognise a difference between the default and that which is installed and ask if the file should be updated.

Comment 1 Tony Vroon (RETIRED) gentoo-dev

2009-03-10 10:58:59 UTC

Please note that you should be overriding the HAL configuration in /etc/hal, not /usr/share/hal (as /usr/share/hal gets overwritten in the next merge).
Also, should you require further information you'll need to include:
- emerge --info
- emerge -pv hal
- the previous version of HAL you used

Comment 2 Neil 2009-03-10 11:28:16 UTC

(In reply to comment #1)
> Please note that you should be overriding the HAL configuration in /etc/hal,
> not /usr/share/hal (as /usr/share/hal gets overwritten in the next merge).

Ahh, ok, I hadn't realised this, thanks for pointing it out.  I'd imagine that will resolve it fine.  I clearly need to do some more reading on how HAL is setup and configured under Gentoo, will see what I can findout.

Cheers

slack