Bug 191329 - scim-bridge must support multilib
Summary: scim-bridge must support multilib
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: scim
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Blocker SCIM 171491
TreeView+ depends on / blocked
 
Reported: 2006-05-10 20:50 UTC by Warren Togami
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-16 06:22:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2006-05-10 20:50:40 UTC
Currently scim-bridge is incapable of working with multilib because its
communication protocol makes incorrect assumptions about data size.  The
protocol must be fixed.

Let's try to get this done before FC6test1 development freeze on June 7th.

Comment 1 Ryo Dairiki 2006-05-12 15:24:15 UTC
I'm sorry to say that I can't afford to makeup all things by the due time.
We must give up at least one thing.

This problem will be solved in scim-bridge-0.2, which now I'm writing.
But I can't prepare this by the begining of June; It will be released at the end
of June at the earliest.

There is another way to solve this, that is, makeup temporary communication
protocol in scim-bridge-0.1.8.
I can makeup this in one week or so.
The problem is that the release of scim-bridge-0.2 will be delaied by such a work.
(Scim-bridge-0.2 will be stable and more memory efficient.
I would like to release this as soon as possible)

Anyway, there is not so much time left for FC6-test1.
We must make a decision as soon as possible.

Comment 2 Ryo Dairiki 2006-05-13 15:51:04 UTC
At last, I've found that it's easy to fix that problem in scim-bridge-0.1.* branch.
Although I haven't tested this (as I'm too sleepy and tired now), 64bit binary
of it must be able to communicate with i386 applications.

You can get scim-bridge-0.1.8 from here:
http://homepage2.nifty.com/shibatama/garage/scim-bridge-0.1.8.tar.gz

Comment 3 Ryo Dairiki 2006-05-14 01:42:53 UTC
At last, I've succeeded in add multilib support for scim-bridge. :)
There are a few changes from the previous post,
please re-download again if you've already got it.

You can get scim-bridge-0.1.8 from here:
http://homepage2.nifty.com/shibatama/garage/scim-bridge-0.1.8.tar.gz

Comment 4 Warren Togami 2006-05-16 04:23:18 UTC
Wow, that was quick, thank you!

It is absolutely critical that scim-bridge works in FC6, so we need to get more
users testing it *now*.  So I plan on rebuilding the entire scim* against
libstdc++.so.6 in FC5 and pushing it as a FC5 update candidate, with scim-bridge
enabled by default.  If testers indicate that it works well, then we will push
it as an official FC5 update.

http://fedoraproject.org/wiki/Core/Schedule
Here is our the FC6 development schedule.  We would need scim-bridge by maybe
July 1st if we want it to be in FC6.  Please let us know how we can help you
complete scim-bridge-0.2 before that time.

What are the key features or improvements coming between 0.1.8 and 0.2?

Comment 5 Jens Petersen 2006-05-16 06:22:08 UTC
Thanks, Dairiki-san: that is great!

Comment 6 Ryo Dairiki 2006-05-16 10:49:40 UTC
> We would need scim-bridge by maybe
> July 1st if we want it to be in FC6.  Please let us know how we can help you
> complete scim-bridge-0.2 before that time.

It could be possible, but difficult.
Maybe it could be tough job. \(x_x)/


> What are the key features or improvements coming between 0.1.8 and 0.2??

ScimBridge-0.1.* use too many threads, which make it difficult to read and
unstable in some cases.
On the other hand, ScimBridge-0.2 will use only GUI thread, so that it won't
cause conflictions between different threads.


I think that's might be such a serious problem.
Because you can upgrade from ScimBridge-0.1.8 to ScimBridge-0.2 without pain.
Just like the transition from ScimBridge-0.1.7 to ScimBridge-0.1.8; They can be
coexist on the same system at the same time.
The old processes continue to use ScimBridge-0.1.7, while the
newly-invoked-processes use ScimBridge-0.1.8.
When there are no clients for ScimBridge-0.1.7, the old agent will gone.
(Did you notice that?)


Note You need to log in before you can comment on or make changes to this bug.