Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 232072 - sys-apps/kbd-1.14.1-r1 - wrong path in init-script pointing to /bin/loadkeys -> loadkeys fails
Summary: sys-apps/kbd-1.14.1-r1 - wrong path in init-script pointing to /bin/loadkeys ...
Status: RESOLVED DUPLICATE of bug 215496
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: PPC Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-17 14:12 UTC by hal
Modified: 2009-02-26 11:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hal 2008-07-17 14:12:39 UTC
hi all,

i'am running gentoo linux on my playstation 3.
i upgraded to kbd-1.14.1-r1. since that time the init-script fails to load the keymaps, because the path is pointing to the wrong directory. instead of using "/usr/bin/loadkeys", it is pointed to "/bin/loadkeys". a manual change in the init-script is working.


Reproducible: Always

Steps to Reproduce:
1. emerge -av kbd-1.14.1-r1
2. /etc/init.d/keymaps restart
3.

Actual Results:  
/etc/init.d/keymaps restart
 * WARNING:  you are stopping a boot service.
 * WARNING:  you are stopping a boot service.
 * Loading key mappings ...
 * /bin/loadkeys not found 

Expected Results:  
/etc/init.d/keymaps restart
 * Caching service dependencies ...                                                                                                                                                                                                   [ ok ]
 * Loading key mappings ...
assuming iso-8859-15 euro                                                                                                                                                                                                             [ ok ]
 * Setting terminal encoding to UTF-8 ...  

change to:

ebegin "Loading key mappings"
        if [[ -x /usr/bin/loadkeys ]] ; then
                [[ ${SET_WINDOWKEYS} == "yes" ]] && WINDOWKEYS_KEYMAP="windowkeys"
                /usr/bin/loadkeys -q ${WINDOWKEYS_KEYMAP} ${KEYMAP} \
                                 ${EXTENDED_KEYMAPS} > /dev/null
                eend $? "Error loading key mappings"
        else
                eend 1 "/usr/bin/loadkeys not found"
                return 1
Comment 1 hal 2008-07-17 23:17:53 UTC
(In reply to comment #0)
> hi all,
> 
> i'am running gentoo linux on my playstation 3.
> i upgraded to kbd-1.14.1-r1. since that time the init-script fails to load the
> keymaps, because the path is pointing to the wrong directory. instead of using
> "/usr/bin/loadkeys", it is pointed to "/bin/loadkeys". a manual change in the
> init-script is working.
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. emerge -av kbd-1.14.1-r1
> 2. /etc/init.d/keymaps restart
> 3.
> 
> Actual Results:  
> /etc/init.d/keymaps restart
>  * WARNING:  you are stopping a boot service.
>  * WARNING:  you are stopping a boot service.
>  * Loading key mappings ...
>  * /bin/loadkeys not found 
> 
> Expected Results:  
> /etc/init.d/keymaps restart
>  * Caching service dependencies ...                                            
>                                                                                
>                                                                       [ ok ]
>  * Loading key mappings ...
> assuming iso-8859-15 euro                                                      
>                                                                                
>                                                                       [ ok ]
>  * Setting terminal encoding to UTF-8 ...  
> 
> change to:
> 
> ebegin "Loading key mappings"
>         if [[ -x /usr/bin/loadkeys ]] ; then
>                 [[ ${SET_WINDOWKEYS} == "yes" ]] &&
> WINDOWKEYS_KEYMAP="windowkeys"
>                 /usr/bin/loadkeys -q ${WINDOWKEYS_KEYMAP} ${KEYMAP} \
>                                  ${EXTENDED_KEYMAPS} > /dev/null
>                 eend $? "Error loading key mappings"
>         else
>                 eend 1 "/usr/bin/loadkeys not found"
>                 return 1
> 

/etc/init.d/consolefont is also affected, as i recognized a second ago, after i had to reboot. instead of pointing to /usr/bin/setfont, the script is pointing to /bin/setfont. the manual "workaround" works like that for "loadkeys".
Comment 2 Mounir Lamouri (volkmar) (RETIRED) gentoo-dev 2008-07-19 13:59:35 UTC
Actually, keympas and consolefont init.d scripts are provided by baselayout. From kbd-1.13* and kbd-1.14.1-r1 loadkeys and setfont binaries has been moved from /bin to /usr/bin but in baselayout-1.12.11.1 init.d scripts (keympas and consolefont at least), path are hard defined so upgrading kbd make these scripts don't working.

This bug comes because kbd-1.14.1-r1 has been unmasked in a stable configuration. The first unstable baselayout ebuild (1.12.12) is working fine with kbd-1.14*.

I don't know the policy about these type of bugs. Does kbd has to RDEPEND on >=baselayout-1.12.12 or baselayout 1.12.11.1 has to rdepend on =kbd-1.13* ? Or does this type of bug has to be ignored has it is a mix of two configurations (stable and unstable) ?
Comment 3 SpanKY gentoo-dev 2008-10-26 06:59:22 UTC

*** This bug has been marked as a duplicate of bug 215496 ***
Comment 4 Mark Wehner 2009-02-25 19:06:41 UTC
This bug also applies to kbd-1.15. Even the old workaround works...
Comment 5 Marcello Magaldi 2009-02-26 11:29:31 UTC
(In reply to comment #4)
> This bug also applies to kbd-1.15. Even the old workaround works...
> 

I simply made two symlinks in /bin :
#cd /bin
#ln -s /usr/bin/loadkeys loadkeys
#ln -s /usr/bin/setfont setfont

for me it is a simpler workaround and no need to touch baselayout scripts (so if you need to re-emerge baselayout you don't have to make this change again)