Description of problem: When starting a GTK program, I'm no getting the error: libuim: [fatal] dynlib: /usr/lib64/uim/plugin/libuim-sqlite3.so: undefined symbol: uim_scm_c_int: Load failed. Some applications crash immediately, some only when you type something, and some work fine. I've temporarily unset GTK_IM_MODULE, but that means that I can't currently use UIM. I installed the uim-qt5 package and it seems that Qt applications have the same issue (I don't have many KDE applications but the ones that I do have crash with QT_IM_MODULE=uim set). The program uim-fep also crashes immediately. It worked fine in Mageia 8, so I don't know what the problem could be (it's still UIM 1.8.8, even though 1.8.9 was released in August 2022). I tried uninstalling and reinstalling all the UIM packages with no luck. I also tried to rebuild and make my own RPMs (using Mageia's SPEC file), but I got errors about circular dependencies and was unable to install the generated RPMs. I also tried ibus and SCIM again, but was reminded how I can't get either to work. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install uim with uim-gtk{,3} and/or uim-qt{4,5} 2. `export GTK_IM_MODULE=uim QT_IM_MODULE=uim` 3. Start a GTK or Qt application from the command line 4. Notice the error and possible crash
Thank you for the report. This SRPM has hardly altered over time, except support for qt4 was dropped in February, so there is now only uim-qt5. Assigning this globally; CC'ing DavidG who did that change in case it matters.
Assignee: bugsquad => pkg-bugsCC: (none) => geiger.david68210
Latest 1.8.9 upstream release should fix this issue, please test it! Assigning to QA, packages in 9/Core/Updates_testing: ====================== libuim8-1.8.9-1.mga9 libgcroots0-1.8.9-1.mga9 libuim-custom2-1.8.9-1.mga9 libuim-scm0-1.8.9-1.mga9 libuim-devel-1.8.9-1.mga9 lib64uim8-1.8.9-1.mga9 lib64gcroots0-1.8.9-1.mga9 lib64uim-custom2-1.8.9-1.mga9 lib64uim-scm0-1.8.9-1.mga9 lib64uim-devel-1.8.9-1.mga9 uim-qt5-1.8.9-1.mga9 uim-gtk-1.8.9-1.mga9 uim-base-1.8.9-1.mga9 uim-gtk3-1.8.9-1.mga9 uim-1.8.9-1.mga9 From SRPMS: uim-1.8.9-1.mga9.src.rpm
Assignee: pkg-bugs => qa-bugs
Advisory with SRPM from comment 2 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"
Keywords: (none) => advisoryCC: (none) => marja11
MGA9-64 Xfce on HP-Pavillion No installation issues. No previous updates, googled and found some tutorial for setting up the uim-database running on MS-SQL-Server, far too complex for me Concentrated on the problem description in th Description above and after installation, launched # uim-toolbar-qt5 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' and that lauched a small toolbar in the lower right corner from the screen, from where I could start a settings window. Same with # uim-toolbar-gtk or # uim-toolbar-gtk3 So the problem seems to be solved.
Whiteboard: (none) => MGA9-64-OKCC: (none) => herman.viaene
Validating.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
I'm still having the problem. Well, uim-fep works now, but I'm still getting that error and crashes with GTK 3 programs. I tried renaming GTK 3's im-uim.so and then creating a symlink from my self-compiled build's im-uim.so to the GTK+ 3 immodules directory and it worked perfectly (I'm guessing because it's using my build's libuim-sqlite3.so). I have no idea why the Mageia 9 builds aren't working but the Mageia 8 ones and my self-compiled ones are, but the configure options of my self-compiled build seem the same as the Mageia 9 RPMs: Configure Result : Anthy : yes Anthy (UTF-8) : yes Canna : no Mana : no PRIME : no SJ3 : no SKK : yes Wnn : no m17n-lib : yes cURL : yes expat : yes OpenSSL : no SQLite3 : yes ffi : no GTK+2 : yes GNOME2 Applet : no GTK+3 : yes GNOME3 Applet : no Qt3 : no Qt3 immodule : no Qt4 : no Qt4 immodule : no Qt4 Qt3Support : no Qt5 : yes Qt5 immodule : yes KDE3 Applet : no KDE4 Applet : no FEP : yes Emacs : yes XIM : yes Pref : yes DICT : yes EB : yes OSX dictionary : no libedit : yes notify : stderr libnotify Default toolkit : gtk
Removing the OK and validation, since the reporter is still having the issue. Marja, I suspect the advisory will eventually have to be changed, but at this point I just don't know.
Whiteboard: MGA9-64-OK => (none)Keywords: validated_update => (none)
(In reply to Thomas Andrews from comment #7) > Removing the OK and validation, since the reporter is still having the issue. > > Marja, I suspect the advisory will eventually have to be changed, but at > this point I just don't know. Thanks, removing the advisory keyword, so that I'll remember to check here whether the advisory in svn needs to be adjusted.
Keywords: advisory => (none)
@Keith Bowes: Could you send me the spec file that you are using yourself at geiger.david68210 at gmail dot com?
I see that the mga8 uim (uim-base) package doesn't provide libuim-sqlite3.so.
(In reply to David GEIGER from comment #9) > @Keith Bowes: > > Could you send me the spec file that you are using yourself at > geiger.david68210 at gmail dot com? I wasn't using a SPEC file. I just did a `./configure --prefix=$(pwd)/ROOT --enable-notify=libnotify --with-eb --with-eb-conf=/usr/lib64/eb.conf --with-qt5 --with-qt5-immodule --with-anthy-utf8 --disable-static --with-curl --with-expat ` in the source directory. As I mentioned before, when I made RPMs, I just got errors about circular dependencies and couldn't install them. (In reply to David GEIGER from comment #10) > I see that the mga8 uim (uim-base) package doesn't provide libuim-sqlite3.so. Yeah, I thought it was odd to specify `--with-sqlite3` explicitly. If there's a problem with libuim-sqlite3.so, it seemed to me that it would have made more sense to do a `--without-sqlite3`, but I'm no expert.
Please test next uim-1.8.9-1.1.mga9 update! If it doesn't work I'll disable sqlite3 support and probably it would be nice to file a new bug upstream to see what they think.
(In reply to David GEIGER from comment #12) > Please test next uim-1.8.9-1.1.mga9 update! > > If it doesn't work I'll disable sqlite3 support and probably it would be > nice to file a new bug upstream to see what they think. @ Keith You seem to be the only one using this, can you please test whether these newer packages are good? x86_64: lib64gcroots0-1.8.9-1.1.mga9.x86_64.rpm lib64uim-custom2-1.8.9-1.1.mga9.x86_64.rpm lib64uim-devel-1.8.9-1.1.mga9.x86_64.rpm lib64uim-scm0-1.8.9-1.1.mga9.x86_64.rpm lib64uim8-1.8.9-1.1.mga9.x86_64.rpm uim-1.8.9-1.1.mga9.x86_64.rpm uim-base-1.8.9-1.1.mga9.x86_64.rpm uim-gtk-1.8.9-1.1.mga9.x86_64.rpm uim-gtk3-1.8.9-1.1.mga9.x86_64.rpm uim-qt5-1.8.9-1.1.mga9.x86_64.rpm or for i586: libgcroots0-1.8.9-1.1.mga9.i586.rpm libuim-custom2-1.8.9-1.1.mga9.i586.rpm libuim-devel-1.8.9-1.1.mga9.i586.rpm libuim-scm0-1.8.9-1.1.mga9.i586.rpm libuim8-1.8.9-1.1.mga9.i586.rpm uim-1.8.9-1.1.mga9.i586.rpm uim-base-1.8.9-1.1.mga9.i586.rpm uim-gtk-1.8.9-1.1.mga9.i586.rpm uim-gtk3-1.8.9-1.1.mga9.i586.rpm uim-qt5-1.8.9-1.1.mga9.i586.rpm
Status: NEW => NEEDINFO
Sorry for not commenting in a while; I rarely check my email (as I rarely get email). OK, here are some new things: 1. Building my own RPMs come with the same problems. There's a circular dependency that uim depends on uim-gtk and uim-gtk depends on uim, but I get around it with `sudo urpmi *uim*.rpm *gcroots*.rpm`, though it installs more packages than I need). 2. Building with `--without-sqlite3` opens a new can of worms. Some programs that previously crashed work, but some of the programs that previously worked now crash (according to gdb, a segfault in libc's `__strlen_sse2`). 3. Compiling it through the normal ./configure; make; sudo make install with the exact same arguments to configure that the RPM's SPEC file specifies doesn't present any of these problems. I can only imagine something is wrong with RPM that strips out `uim_scm_c_int`. Well, doing it this way does still have one problem: A crash in Qt programs running in Wayland (but that's an upstream issue; the workaround is to specify `-platform xcb` to the Qt program, but I submitted a PR upstream to fix the issue (reported in 2020 but strangely unfixed), so hopefully that workaround won't be necessary in the next version of uim). > (In reply to Marja Van Waes from comment #13) > > You seem to be the only one using this, can you please test whether these > newer packages are good? I find it hard to believe that I'm the only one using it. I tried out various input methods (like the inexplicably more popular ibus and scim) when I switched to Wayland (and thus my xmodmap no longer worked) before discovering uim and realizing it was clearly the best (easy-to-use, unintrusive, and modifying layouts is as simple as editing some Scheme files, plus it works in KMS (and terminal emulators) through uim-fep, so you don't even have to use a graphical environment to type special characters easily). But the answer is no: 1.8.9-1.1 has the same issues as 1.8.8-10.
David Rosa https://abf.io/import/uim/tree/rosa2021.1 and fedora https://src.fedoraproject.org/rpms/uim/tree/rawhide apply some patches to this version I not sure what set of patches will be the best for us