To put it simple: API change in gucharmap, for pkg-config gucharmap became gucharmap-2. Can't tell yet how hard will be porting.
Created attachment 174199 [details, diff] libtomoe-gtk-0.6.0-gucharmap2.patch this patch allows libtomoe-gtk to detect the new gucharmap but it won't build because of the API changes.
Created attachment 174201 [details, diff] libtomoe-gtk-0.6.0-gucharmap2.patch better patch that updates libtomoe-gtk use of the gucharmap API. It doesn't look really clean to keep compatibility with the older API so I'll wait on @cjk input to see what they want to do. For now, it seems fedora just disable the gucharmap integration.
posted the issue upstream.
Created attachment 174432 [details, diff] patch to build scim-tomoe with gucharmap2 As a companion to your patch, I'm dropping mine: it for scim-tomoe 0.6.0. I'm not sure if it's correct, but tomoe seems to work.
As a sidenote - regarding your patch: you should add a block adding ACLOCAL_AMFLAGS = macros to the top level Makefile.am, so eautoreconf just works.
(In reply to comment #5) > As a sidenote - regarding your patch: > you should add a block adding ACLOCAL_AMFLAGS = macros > to the top level Makefile.am, so eautoreconf just works. > This is intentional, my goal is to fix gucharmap API usage, not autofoo here.
@cjk, please comment on those patch, how would you like to see them in portage and whatnot, I don't really want to step on someone's toes.
sorry for delay. I think it should be handled by #if pragma for both gucharmap and gucharmap2 api. I'll contact to upstream soon.
Created attachment 176020 [details] libtomoe-gtk-0.6.0-gucharmap2.patch this patch is based on http://lists.sourceforge.jp/mailman/archives/tomoe-devel/2008-December/000197.html. Could you test this?
Hum overlooking further discussion on upstream ml, it seems this patch is not enough. It is a bit simpler than mine but I don't really like adding that much #ifdefs :). Anyway we'll stick to upstream choice if they come up with something better.
this patch doesn't seem to apply on the version in tree. I'll fix it tomorrow nigth and commit if it's ok for you. With scim fixes too.
Included in 0.6.0-r1 bump for libtomoe-gtk and 0.6.0-r2 for scim-tomoe. Thanks for refining the patch and working with upstream.
libtomoe-gtk-0.6.0-r1 still doesn't compile with the doc flag enabled. gtk-doc: Compiling scanner libtool: compile: x86_64-pc-linux-gnu-gcc -I../../src -I../../src -I/usr/include/tomoe -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -c libtomoe-gtk-scan.c -fPIC -DPIC -o .libs/libtomoe-gtk-scan.o In file included from ../../src/tomoe-gtk.h:36, from libtomoe-gtk-scan.c:7: ../../src/tomoe-gucharmap.h:27:33: error: gucharmap/gucharmap.h: No such file or directory
that would be with USE="-gucharmap" I believe. Well that's another bug then. Please fill a new one with a reference to an upstream bug. Thanks.
(In reply to comment #14) > that would be with USE="-gucharmap" I believe. Well that's another bug then. > Please fill a new one with a reference to an upstream bug. Thanks. > Nope. gucharmap is on, and gucharmap and doc mutually exclude each other. Either gucharmap or doc build, but not both. Notice it's looking for gucharmap.h, but '-I/usr/include/gucharmap-2' is missing, which leads to failure.
reopening before I forget to fix that.
fixed without a bump as this affects only users have USE="doc".
*** Bug 262367 has been marked as a duplicate of this bug. ***
what was exactly the fix? I've just made a eix-sync and I'm trying to compile scim-tomoe and libtomoe-gtk cannot be configured because of "gucharmap >= 1.4.0". I also tried enabling and disabling the 'doc' flag but it didn't worked. It seems not fixed for me :(
It's fixed by keywording libtomoe-gtk-0.6.0-r1 (which should have a stable request by now, BTW)
*** Bug 438202 has been marked as a duplicate of this bug. ***