FFe: migrate to ibus-1.3 series
happyaron.xu at gmail.com
Thu Sep 2 18:04:51 BST 2010
On Thu, Sep 02, 2010 at 03:22:06PM +0200, Krzysztof Klimonda wrote:
> On Thu, 2010-09-02 at 19:52 +0800, Aron Xu wrote:
> > I think this topic worth a discussion, serious memory leak is found
> > in
> > an important CJK support part that included to LTS CD images but is
> > hard
> > to get it fixed.
> Is the memory leak really that serious? Bug report mentions "130MB
> few days", I wouldn't call that serious - especially that there are at
> least two simple workarounds: Shut down your computer when you go to
> sleep/home or restart process.
Memory leak is very noticable when a user is actually typing many
things - you could read there are someone saying that typing every word
making it leak more. Ubuntu requires only 384MB RAM for an installation,
butonly an input method will take around 300MB when there is memory
The description of that bug only indicates on of the two process that
probably has memory leak. The another one will use up another 100MB
memory when the leak appears.
The workaround doesn't fix the security risk caused by the memory leak.
> If we really don't have active maintainers for ibus stack in Ubuntu
> backporting whole stack to Lucid may be risky - we can introduce
> regressions that aren't as easily worked around as the memory leak
> There are 12 different ibus dependant packages, would all of them have
> to be updated? Some are probably used only be a small number of people
> will they get enough testing for regressions once the land in
There isn't active maintainer in Ubuntu, but the software has an active
upstream, and there are a team who are maintaining the packages actively
in Debian. When there is nobody taking care of fixing bugs, it makes no
sense to say updating to a working branch which resolves many bugs are
facing risks. The good point for not updating to a newer version is
don't have the risk of regressions; the risk of not updating is old bugs
that already fixed upstream cannot be applied to our packages (firstly
changes are not easy to backport, secondly we are lacking for
Not all of the related packages need to be updated, the update from 1.2
to 1.3 only updates the C/C++ interface, and Python part is not changed,
so many packages don't actually need an update. Here is list of packages
that is the most important for QA: ibus, ibus-pinyin, ibus-chewing,
ibus-anthy and ibus-hangul.
> And also is 1.3 going to be supported by upstream for a longer time or
> are we going to have the same problem if some bug is discovered in 1.3
> and upstream suggests updating to 1.4?
The problem was, when upstream suggests updating to 1.3, we are still in
Lucid development cycle but decided to not update. And the problem is,
for now, whether an update to 1.3 is worthy, but not stuck at
discussions about whatif the same situation happen with Lucid support
cycle goes on. With the cycle goes by, more and more users will upgrade
to newer releases. Those who have chosen to stay with an LTS just want
to have a solid platform for their deployment, so whether this update
provide better stability is our key topic here.
> Does #625696 affect 10.04? It's not mentioned in the report, #329898
> does look like something that would be nice to get fixed but again -
> it important enough to risk regressions?
The two bugs I listed are bugs we should give a fix before Maverick
release, they also should be fixed if we decide to have an SRU.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100903/2f9d2cf8/attachment-0001.pgp
More information about the ubuntu-devel