Chewing has moved out of the xcin project and becomes libchewing. Therefore the xcin package in the portage will outdate pretty soon. The following ebuilds attached are ebuilds for libchewing and xcinqoo (qoo is the new name for chewing input) They are currently maintained by Gentoo Taiwan. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 32097 [details] libchewing libchewing
Created attachment 32098 [details] xcin-patched with libchewing Official homepage: (it in zh_TW.Big5) http://jserv.sayya.org/wiki/index.php/Qooing
liquidx: you want to look into it?
Created attachment 32802 [details] update
Benny, what do you think is the best name for the package?
the best name should be xcin-chewing. I am also sure that the current xcin in the portage is heavily outdated. If possible, this should be a replacement. I have some testers tested the ebuild, it's working like a charm. It should be stable.
Created attachment 33646 [details] app-i18n/libchewing/libchewing-0.2.1.ebuild
I'm looking into your ebuild. It doesn't have LICENSE variable and I cannot find any documents regarding its license. Do you know anything about it, or could you ask the upstream author about it? Also, could you elaborate more on libchewing in DESCRIPTION? As for your ebuild, you set MAKEOPTS in libchewing-0.2.1.ebuild, but it is not recommended. -- cd ${WORKDIR} unpack `basename ${SRC_URI}` -- is redundant since src_unpack() default working directory is ${WORKDIR} and you can use ${A} for everything in ${SRC_URI}. (If you want to do the same thing by hand, just write "unpack ${A}") I moved DESTDIR hack to src_install, so all the perl stuff aren't needed and then you can remove src_unpack() from your ebuild. Again, "cd ${S}" in src_compile() and src_install() aren't needed. They default to ${S}. See `man 5 ebuild` for detail. Thanks in advance.
Created attachment 33721 [details] removed unstable warning removed the unstable warning, tested no problem with 10 users. the license is GPL, thanks for the important note! :)
Thanks for the clarification. I committed dev-libs/libchewing (we keep app-i18n for input methods frontend and so on, and put libraries needed by them to dev-libs). As for your xcin-chewing ebuild, I cannot find patches for it. Could you attach them here? Some additional comments on your ebuild: * Package version number should not be hardcoded to ${XCIN}. Use ${PV} instead. (XCIN="xcin-cvs-${PV}.tbz2", which is easy to update) * Please use epatch in src_unpack() rather than calling `patch -p1` by hand. You don't need to cp xcin-chewing.diff to ${S} but write `epatch ${FILESDIR}/xcin-chewing.diff`. * I'm not sure but doesn't xcin-chewing block xcin? At least /etc/xcinrc from both ebuilds conflict with each other.
Created attachment 33734 [details] app-i18n/xcin/xcin-2.5.3_pre3-r1.ebuild this ebuild includes utf8 and libchewing
Created attachment 33735 [details] app-i18n/xcin/files/xcin-chewing.diff
Adding the current maintainer. sorry that I added the very early version of the ebuild :(
Thanks for the update, bug I'm confused. Do you want this ebuild as separate package from xcin (then we will have app-i18n/xcin and app-i18n/xcin-chewing), or you want it to just upgrade to xcin (then we will have only app-i18n/xcin)? About the updated ebuild, * HOMEPAGE is a space separated list of homepages. You don't need to put '&&' there. * We don't have utf8 global IUSE flag. We use unicode IUSE flag for that purpose (It covers utf8, utf16 and so on). * rpm2targz should not be RDEPENDed. You need it only at unpacking stage, so please remove it from RDEPEND. -- RDEPEND="dev-libs/libchewing ... unicode? ( media-fonts/hkscs-ming )" DEPEND="${RDEPEND} >=app-arch/rpm2targz-9.0-r2" -- * Also, you can use rpm.eclass for unpacking rpms. * Do not set MAKEOPTS in ebuild. Instead, use "emake -j1 || die".
Sorry, newlines were deleted. I repost it. Thanks for the update, bug I'm confused. Do you want this ebuild as separate package from xcin (then we will have app-i18n/xcin and app-i18n/xcin-chewing), or you want it to just upgrade to xcin (then we will have only app-i18n/xcin)? About the updated ebuild, * HOMEPAGE is a space separated list of homepages. You don't need to put '&&' there. * We don't have utf8 global IUSE flag. We use unicode IUSE flag for that purpose (It covers utf8, utf16 and so on). * rpm2targz should not be RDEPENDed. You need it only at unpacking stage, so please remove it from RDEPEND. -- RDEPEND="dev-libs/libchewing ... unicode? ( media-fonts/hkscs-ming )" DEPEND="${RDEPEND} >=app-arch/rpm2targz-9.0-r2" -- * Also, you can use rpm.eclass for unpacking rpms. * Do not set MAKEOPTS in ebuild. Instead, use "emake -j1 || die".
okay, to make it less confusing, i've edited the name of the attachment to the location of the file where it should be appear in the portage tree. 1. the attachments should be placed into two packages, one in a new package named "libchewing", another in the current "xcin". 2. mentioned bugs fixed.
Created attachment 33744 [details] app-i18n/xcin/xcin-2.5.3_pre3-r1.ebuild
Thanks Palatis. I figured out what you mean. I added xcin-2.5.3_pre3.ebuild to CVS (-r1 isn't necessary since this is the first introduction of the version to Portage). If you experience any problem, please let us know. btw, you seem to have iiimf-xcin and xim-select on your local tree. Are you interested in supporting IIIMF in Gentoo? I committed app-i18n/im-sdk (and other ebuilds depending on it) last year but still not sure about its stability. If you could help us with it I'd be very appreciated.
as far as i known, iiimf will replace xim sooner or later, but now it is unstable. I personally do not recommend to use it.
that iiimf-xcin in gentoo.org.tw local portage tree does compile but does *NOT* work. we're trying to figure out why and trying to make it useable. as Jackey said, iiimf is still kinda in a experimantal stage and not really *useable*... please don't add that iiimf-xcin, yet. since its currently not working. for xim-select, its a easy script to switch between XIMs, it is (probably) extansible, such as add Japanese & Korean IMs into it. but i'm not using such IMs so I'm not going to add them. besides, after iiimf is ready, we won't need that xim-select anymore. but, add xim-select into portage tree is preferable :)
sorry for the reopening, the libchewing in current portage tree is a old version too = = benny must be submitting these ebuilds at some kinda early stage.
Created attachment 33807 [details] dev-libs/libchewing/libchewing-0.2.1.ebuild
Your version supports CFLAGS so I'll add it to the ebuild, but I don't think other stuffs are needed. * You seem to misunderstand difference between DEPEND and RDEPEND. DEPEND is for build time depencency and RDEPEND is for runtime dependency. In your ebuild perl is necessary only at build time, so it should be -- DEPEND="dev-lang/perl" RDEPEND="" -- * If you use append-flags, you need to inherit flag-o-matic. Similar thing applies to epatch. You should inherit eutils in order to use epatch. (not in this ebuild but I thought I saw you using epatch without inheriting eutils somewhere else) If you are using portage-2.0.50, append-flags and epatch work without them since extra_functions.sh provides those functions, but extra_functions.sh will be removed from the next release, 2.0.51. * Is there really need for append-flags here? As I see build process "-I./include" is automatically added. For other things please refer to my Comment #8
oic :) sorry for my n00b ebuild coding style ><
No worries :) I understood why you added append-flags when I added CFLAGS="${CFLAGS}" to emake -j1. Thanks for the update. About iiimf-xcin and xim-select, I don't add them unless you post them to bugzilla ;) There isn't handy way to switch XIMs atm, xim-select may be useful for users who want to use several IMs. If you think it is worth commiting to Portage, please open a new bug for it and I'll add it to CVS. Apart from IIIMF, I'm surprised how easily I can switch input methods with XIM bridge for SCIM. Have any of you tried app-i18n/scim-0.99.0? I'm interested in what Chinese users say about it. (stability, quality of conversion, etc)
*cough* time for me to show up..it works fine. scim has a pretty interface (comparing with xcin). it support many IMs but I finally switched back to xcin. The reason is the uneasiness of handeling. (maybe it's just because of the personal flavor).
new bug opened #54872 for xim-select.
