kbd (m17n) unavailable

[Tyrn]

Under Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old Church Slavonic only glag (m17n) is available via ibus-setup.

$ ibus list-engine

...
language: Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old Church Slavonic
  m17n:cu:glag - glag (m17n)
...
language: Russian
  m17n:ru:phonext - phonext (m17n)
  m17n:ru:ext - ext (m17n)
  m17n:ru:phonetic - phonetic (m17n)
  xkb:ru::rus - Russian
  m17n:ru:translit - translit (m17n)
  xkb:ru:phonetic:rus - Russian (phonetic)
  m17n:ru:yawerty - yawerty (m17n)
...

Package installed: m17n-cu_1.1.0_all.deb

Files installed:

m17n-cu /usr/
m17n-cu /usr/share/
m17n-cu /usr/share/doc/
m17n-cu /usr/share/doc/m17n-cu/
m17n-cu /usr/share/doc/m17n-cu/changelog.gz
m17n-cu /usr/share/doc/m17n-cu/copyright
m17n-cu /usr/share/i18n/
m17n-cu /usr/share/i18n/locales/
m17n-cu /usr/share/i18n/locales/cu_RU
m17n-cu /usr/share/m17n/
m17n-cu /usr/share/m17n/cu-glag.mim
m17n-cu /usr/share/m17n/cu-kbd.mim
m17n-cu /usr/share/m17n/cu.lnm
m17n-cu /usr/share/m17n/icons/
m17n-cu /usr/share/m17n/icons/cu-glag.png
m17n-cu /usr/share/m17n/icons/cu-kbd.png
m17n-cu /usr/share/m17n/icons/ru-ext.png
m17n-cu /usr/share/m17n/icons/ru-phonext.png
m17n-cu /usr/share/m17n/ru-ext.mim
m17n-cu /usr/share/m17n/ru-phonext.mim

Locales:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

System: Arch Linux

[EliseyP]

Подобная проблема для Debian - после обновления с 9 до buster пропала обычная цся-раскладка, осталась только глаголица.

При этом
$ /usr/lib/ibus/ibus-setup-m17n --name "m17n:cu:kbd"
запускает конфигуратор для этого engine

[Tyrn]

You mean, this is a workaround?

[EliseyP]

The problem is solved.
I get

$ /usr/lib/ibus/ibus-engine-m17n cu:kbd
...
ibus-m17n-Message: 19:38:46.845: skipped m17n:cu:kbd since its rank is lower than 0
...

Problem in default settings in
/usr/share/ibus-m17n/default.xml
In this file we have this lines:

    <!-- Blacklist some engines -->
    <!-- kbd engines are duplicate of xkb engines -->
    <engine>
            <name>m17n:*:kbd</name>
            <rank>-1</rank>
    </engine>

I add this lines:

    <engine>        
            <name>m17n:cu:kbd</name>
            <rank>2</rank>
    </engine>

and ibus now see this engine.

[EliseyP]

For developers:
look at this post [https://github.com/ibus/ibus-m17n/issues/8]
with new version of ibus-m17n (1.4.1) peoples can have similar problems.

[typiconman]

Seems that this issue is now solved? At least, I cannot reproduce it under IBus 1.5.17.

[Tyrn]

I use m17n-cu 1.1.0-1 with the workaround and iBus 1.5.21. To tell you something meaningful I'll have to know your (the last?) version of m17n-cu.

[typiconman]

The current version is 1.2.1, but I have not changed anything with the cu:kbd layout. It seems to be working fine on iBus

$ ibus version
IBus 1.5.17

$ ibus list-engine | grep "cu"
  m17n:cu:glag - glag (m17n)
  m17n:cu:znamstd - znamstd (m17n)
  m17n:cu:znampar - znampar (m17n)
  m17n:cu:kbd - kbd (m17n)

[Tyrn]

m17-cu 1.2.4

$ ibus version
IBus 1.5.22
$ ibus list-engine | grep "cu"
  m17n:cu:znamstd - znamstd (m17n)
  m17n:cu:znampar - znampar (m17n)
  m17n:cu:glag - glag (m17n)

Apparently, the workaround is still in order. Do you need any additional info?

[Tyrn]

m17n-cu 1.2.4

$ ibus version
IBus 1.5.22
$ ibus list-engine | grep "cu"
  m17n:cu:znamstd - znamstd (m17n)
  m17n:cu:znampar - znampar (m17n)
  m17n:cu:kbd - kbd (m17n)
  m17n:cu:glag - glag (m17n)

m17n:cu:kbd - kbd (m17n) appeared only after applying the old workaround:
/usr/share/ibus-m17n/default.xml:

...
    <engine>        
            <name>m17n:cu:kbd</name>
            <rank>2</rank>
    </engine>

So we are back at square one.

Probably, default.xml is not the right place to put the patch in, as it gets overwritten sometimes. Probably, your package relies on certain Debian/Ubuntu specific defaults, so you have no problems.