Bug#746968: ibus-array should be removed
Hi, On Mon, May 05, 2014 at 02:26:44AM +0800, Keng-Yu Lin wrote: > As an Array 30 IM user, the ibus-table-array30 package did not > implement the full features of the Array 30 IME (such as no quick > codes, no first and second class simple codes) where ibus-array > implemented these extra features. > > Also as the package maintainer of ibus-array package, I am happy and > will spend some time looking at the ibus-python issue. Great. Please check what did ibus-pinyin package did between 1.4.0 to 1.5.0 upstream versions to get the feel of migrating to Gobject Introspection based bindings. These seems to be useful git repo for ibus-pinyin https://github.com/ibus/ibus-pinyin.git https://github.com/phuang/ibus-pinyin.git Maybe this commit ... https://github.com/phuang/ibus-pinyin/commit/4950900e3acc6cf0741962179e2b2b924964ae4f which has changes such as; # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -import sys -import gtk -import ibus + +import gettext import locale import os -import version -import gettext +import sys + +from gi.repository import GLib +from gi.repository import Gtk +from gi.repository import IBus from xdg import BaseDirectory +import version If upstream is stalled, you may think about taking over upstream. Osamu Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746968: ibus-array should be removed
As an Array 30 IM user, the ibus-table-array30 package did not implement the full features of the Array 30 IME (such as no quick codes, no first and second class simple codes) where ibus-array implemented these extra features. Also as the package maintainer of ibus-array package, I am happy and will spend some time looking at the ibus-python issue. 2014-05-04 20:49 GMT+08:00 Osamu Aoki : > Source: ibus-array > Version: 0.0.2-9 > Severity: normal > > In short, we should remove this ibus-array package. > > The reason is that ibus-array is one of the few packages which still > uses ibus-python interface which is about to be removed from ibus(*). > > * ibus-array popcon=ca. 30 (uses ibus-python) > * ibus-table-array30 popcon=ca. 30 (does not use ibus-python) > > Since the ibus-table-array30 binary package which is generated from the > ibus-table-chinese source package seems to support this particular > array30 chinese input method, I see no major problem. (I also see a low > popcon value.) > > So question is what to do for wheezy. 3 options. > > 1) we just remove ibus-array. (My choice) > 2) we upload transition package of ibus-array depending on > ibus-table-array30. > 3) we modify ibus-table-array30 to provide ibus-array. >(need ibus-table-chinese source package upload) > > Unless I get specific request/help/... , I will just do option 1 to > remove this ibus-array. Objection? > > Let me know your thought by replying to this Debian bug report. Once we > decide on this, I can work on other 3 packages which are affected. > > * ibus-pinyin popcon=443 >ibus-pinyin needs to update its package dependency so it can be >removed from this list. I will handle this separately. > > * ibus-googlepinyin popcon=330 >Considering other newer pinyin methods are available, simply removing >this should be OK just like ibus-array. > > * ibus-el popcon=103 >Whoever uses this with EMACS should consider using uim instead since >they can stay within LISP world using uim bindings of IM. > > Regards, > > Osamu > (*) ibus-python removal background. > The upstream does not actively support ibus-python and has been > recommending to move to use Gobject introspection. So continuing to > ship unsupported zombie ibus-python code just because its old code has > not been removed is not good idea. > > Since most of the IM packages completed this transition, I am planning > to remove ibus-python. > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746968: ibus-array should be removed
Source: ibus-array Version: 0.0.2-9 Severity: normal In short, we should remove this ibus-array package. The reason is that ibus-array is one of the few packages which still uses ibus-python interface which is about to be removed from ibus(*). * ibus-array popcon=ca. 30 (uses ibus-python) * ibus-table-array30 popcon=ca. 30 (does not use ibus-python) Since the ibus-table-array30 binary package which is generated from the ibus-table-chinese source package seems to support this particular array30 chinese input method, I see no major problem. (I also see a low popcon value.) So question is what to do for wheezy. 3 options. 1) we just remove ibus-array. (My choice) 2) we upload transition package of ibus-array depending on ibus-table-array30. 3) we modify ibus-table-array30 to provide ibus-array. (need ibus-table-chinese source package upload) Unless I get specific request/help/... , I will just do option 1 to remove this ibus-array. Objection? Let me know your thought by replying to this Debian bug report. Once we decide on this, I can work on other 3 packages which are affected. * ibus-pinyin popcon=443 ibus-pinyin needs to update its package dependency so it can be removed from this list. I will handle this separately. * ibus-googlepinyin popcon=330 Considering other newer pinyin methods are available, simply removing this should be OK just like ibus-array. * ibus-el popcon=103 Whoever uses this with EMACS should consider using uim instead since they can stay within LISP world using uim bindings of IM. Regards, Osamu (*) ibus-python removal background. The upstream does not actively support ibus-python and has been recommending to move to use Gobject introspection. So continuing to ship unsupported zombie ibus-python code just because its old code has not been removed is not good idea. Since most of the IM packages completed this transition, I am planning to remove ibus-python. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
