Prior to 2025.02.16 update, I was using Ibus as my input method for alternative language.
After the update, all my input method listed in Ibus Preference, has been wiped.
In addition, the update has forced the installation of fcitx5, which has Keyboard - English (US) as default, without any other language input available.
Left click the tray icon, has no action.
Right click the tray icon, shows a menu, and the Configure option in the menu, brings up ~/.config/fcitx5 without any explanation nor choice.
I’m puzzled:
I presume this forced change comes from KDE rather than Manjaro? They are deciding, on behalf on user, that users must not use Ibus, and thus has removed all users settings in Ibus?
The forced installation of fcitx5 does not work immediately - there is no input method provided in fcitx5 other than the US keyboard. I cannot immediately input in alternative language. And since the configuration provides no explanation, I have to spend time to research - how to type in my desired alternative language. Is this update causing me more issues, or solving issues for me?
Thanks!
I really dun have the time to go through the documentations, while I’ve things to do.
And I have prior unpleasant experience trying to setup fcitx5.
The question remained:
Should KDE dictate which input tool users should use, by wiping clean the input method of ibus, and force-installed fcitx5 that has no input method?
pacman -Qi fcitx5 127 ✘
Name : fcitx5
Version : 5.1.12-1
Description : Next generation of fcitx
Architecture : x86_64
URL : https://github.com/fcitx/fcitx5
Licenses : LGPL-2.1-or-later AND Unicode-DFS-2016
Groups : fcitx5-im
Provides : None
Depends On : cairo enchant iso-codes libgl libxkbcommon-x11 pango systemd wayland xcb-imdkit xcb-util-wm libxkbfile gdk-pixbuf2 json-c
Optional Deps : None
Required By : fcitx5-rime
Optional For : None
Conflicts With : fcitx
Replaces : None
Installed Size : 17.18 MiB
Packager : Felix Yan <felixonmars@archlinux.org>
Build Date : Sat 01 Feb 2025 01:55:59 AM +08
Install Date : Wed 19 Feb 2025 04:27:19 AM +08
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
I should highlight that I installed fcitx5-rime AFTER @scotty65 help.
So without fcitx5-rime, fcitx5 is not required by anything.
Have to ask KDE team, right?
I’m particularly irritated by their dictator’s behavior, and their update simply caused me to lose more time, instead of save more time.
These are all the entries from the beginning of the update, till fcitx5 was installed.
I must also highlight that: prior to 2025.02.16 update, I did not have fcitx5 installed - i was using ibus.
So this might be related.
I note that sdl2 is (somewhat newly) in the AUR.
You may have only recently experienced this due to being on Manjaro Stable.
I also note that sdl2 does depend on fcitx5 as a make depend … meaning it is only required in order to build the package.
Probably something to do with these things?
I also might wonder whether this was a pamac upgrade?
make depends are only for AUR packages … you dont build repo packages. sdl2-compat in no way requires fcitx5.
And make depends doesnt mean Required By - that was my point - they mean the package is needed to build the package, but are not ‘Required By’ them.
But I would not be surprised if pamac somehow got confused.
Something like “sdl2 will require fcitx5 to build so install it, but also replace sdl2 with sdl2-compat” and then no clean up or removal of orphans or similar.
(you may note you also got cmake for some reason … it is also a build dependency of sdl2)
Well, either way, build depends dont matter for repo packages…
I guess we can wonder if @wind77 somehow has foreign packages?
But they arent - or else they would be labeled *-git and so on.
Though … for that month or so prior there would have been sdl2 in both the Stable repos and the AUR … so maybe it got built at some point during that time?
Make dependencies dont exist for pre-built repo packages.
There is nothing to make.
When considered alongside the use of pamac this seems the most likely candidate for me - whether it occurred previously and established the AUR package or was created by some confusion during this single transaction.
Is an input method required by sdl2 and sdl3 now, where it was not required prior to 2025.02.16 update?
And such requirement, mandated me to switch input method from Ibus to fcitx5?
And to ensure my compliance, my input method in ibus was wiped cleaned?
And if I choose to “defy” such mandate, is it safe for me to remove fcitx5?
Would future update enforce “compliance” from me again?
Well, its not definitive but so far I am tending towards
Something with sdl2 being in the AUR and have the fcitx5 build depend and the use of pamac (repo+aur).
Nope. Neither sdl2-compat nor sdl3 require fcitx5.
Even if you reverted to sdl2 from the AUR fcitx5 would still not be required except to build the package.
( Aside from not exhibiting the issue of source ‘confusion’, every competent AUR helper provides ways to automatically remove build depends after transactions. Let alone removing the AUR from the equation and using pacman alone - I doubt would have created this scenario. [Would be an interesting test if someone uses backups. ])
I dont know why you are so eager to paint this with overtures to authoritarianism.
Its just a package exchange.
( even if an undesirable one )
But yes, you can safely remove fcitx5 and related packages … as shown by the dependencies.
])