[opensuse-m17n] IBus 1.5
Hi, all, IBus 1.5 was released several days ago. It is major update. How do we update packages related to ibus? - ibus-* depending on ibus 1.5's typelib (developed in python) is not compatible with 1.4. We must update "Requires" tag. - Compatibility of two versions of libibus is not clear. ibus-mozc linked to 1.4's libibus could communicate with ibus 1.5 as far as I tested. - Do we need to clean up its package's change log while it was in the M17N/Devel project? - The released version still have something wrong. For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?) I think we should put all ibus-related packages into a clean sub-project and test them carefully before updating M17N/ibus. Do you have any idea to update ibus? Best regards and have a lot of fun, Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Thu, 13 Dec 2012 01:42:25 +0900, Fuminobu TAKEYAMA wrote:
Hi, all,
IBus 1.5 was released several days ago. It is major update.
Takeyama-san, thanks for heading up. I also wanted to ask about this now, too :)
How do we update packages related to ibus?
- ibus-* depending on ibus 1.5's typelib (developed in python) is not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
- Compatibility of two versions of libibus is not clear. ibus-mozc linked to 1.4's libibus could communicate with ibus 1.5 as far as I tested.
This is always a potential breakage in every shared library package, and I don't think we can do so much for it. All related packages in the project (thus later in FACTORY once when ibus-1.5 is checked in) will be rebuilt in anyway, so unless user does strange things, user will get consistent packages from the same project (in theory). But if the backward compatibility isn't kept, basically the shared lib must increase its *.so version number. If they didn't, it's a clear bug of ibus.
- Do we need to clean up its package's change log while it was in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least. So we need to merge the changelog, maybe with a bit of clean up.
- The released version still have something wrong. For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
I think we should put all ibus-related packages into a clean sub-project and test them carefully before updating M17N/ibus.
Yes, let's put all ibus-related packages to M17N:Devel at first (just do branch or linkpac), then watch the build status. thanks, Takashi
Do you have any idea to update ibus?
Best regards and have a lot of fun,
Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wednesday 12 December 2012 17:57:28，Takashi Iwai :
At Thu, 13 Dec 2012 01:42:25 +0900,
Fuminobu TAKEYAMA wrote:
Hi, all,
IBus 1.5 was released several days ago. It is major update.
Takeyama-san, thanks for heading up. I also wanted to ask about this now, too :)
How do we update packages related to ibus?
- ibus-* depending on ibus 1.5's typelib (developed in python) is
not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
- Compatibility of two versions of libibus is not clear.
ibus-mozc linked to 1.4's libibus could communicate with ibus 1.5 as far as I tested.
This is always a potential breakage in every shared library package, and I don't think we can do so much for it. All related packages in the project (thus later in FACTORY once when ibus-1.5 is checked in) will be rebuilt in anyway, so unless user does strange things, user will get consistent packages from the same project (in theory).
But if the backward compatibility isn't kept, basically the shared lib must increase its *.so version number. If they didn't, it's a clear bug of ibus.
- Do we need to clean up its package's change log while it was
in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least.
So we need to merge the changelog, maybe with a bit of clean up.
- The released version still have something wrong.
For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
AFAIK this is what it supposed to be. (Though I have nothing to do with IBus dev.. I'm just the one who also keeps an eye on ibus) The new behavior is changed to something like MAC, ctrl+space in ibus-1.5 now behave like alt+tab (kinds of stack based), most recent accessed is the next one being switched by ctrl+space.
Hello,
- ibus-* depending on ibus 1.5's typelib (developed in python) is
not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
Python is a dynamic language so we can see, for example, method missing error at runtime. latter one?
- Do we need to clean up its package's change log while it was
in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least.
So we need to merge the changelog, maybe with a bit of clean up.
The package of ibus-1.5 have been separately developed in M17N/Devel and not been submitted to Factory. It has several change log entries for ibus-1.4.99.x. I think changes from 1.4 to 1.5 is not clear from the log but it is not so problematic: https://build.opensuse.org/package/view_file?expand=1&file=ibus.changes&package=ibus&project=M17N%3ADevel # Oh, it is not linked to M17N/ibus...
- The released version still have something wrong.
For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
Maybe. We can add Zenkaku Hankaku key for Japanese by adding a file to /etc/dconf/profile but I don't know which binding is active. I'll try.
I think we should put all ibus-related packages into a clean sub-project and test them carefully before updating M17N/ibus.
Yes, let's put all ibus-related packages to M17N:Devel at first (just do branch or linkpac), then watch the build status.
Unfortunately, since we don't have any rules about M17N:Devel, it is not clean and has a lot of packages. # I cannot run zypper dup -r M17N:Devel Shall we make a new subproject M17N:Testing like openSUSE:*:*:Testing for packages that should be merged into M17N soon? Or clean up M17N:Devel? Hi, Weng,
AFAIK this is what it supposed to be. (Though I have nothing to do with IBus dev.. I'm just the one who also keeps an eye on ibus)
The new behavior is changed to something like MAC, ctrl+space in ibus-1.5 now behave like alt+tab (kinds of stack based), most recent accessed is the next one being switched by ctrl+space.
I know but I guess the developers try to provide additional keys for switching stacked IMs for each keyboard layout. Fuminobu TAKEYAMA (2012/12/13 5:05), Weng Xuetian wrote:
On Wednesday 12 December 2012 17:57:28，Takashi Iwai :
At Thu, 13 Dec 2012 01:42:25 +0900,
Fuminobu TAKEYAMA wrote:
Hi, all,
IBus 1.5 was released several days ago. It is major update.
Takeyama-san, thanks for heading up. I also wanted to ask about this now, too :)
How do we update packages related to ibus?
- ibus-* depending on ibus 1.5's typelib (developed in python) is
not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
- Compatibility of two versions of libibus is not clear.
ibus-mozc linked to 1.4's libibus could communicate with ibus 1.5 as far as I tested.
This is always a potential breakage in every shared library package, and I don't think we can do so much for it. All related packages in the project (thus later in FACTORY once when ibus-1.5 is checked in) will be rebuilt in anyway, so unless user does strange things, user will get consistent packages from the same project (in theory).
But if the backward compatibility isn't kept, basically the shared lib must increase its *.so version number. If they didn't, it's a clear bug of ibus.
- Do we need to clean up its package's change log while it was
in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least.
So we need to merge the changelog, maybe with a bit of clean up.
- The released version still have something wrong.
For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
AFAIK this is what it supposed to be. (Though I have nothing to do with IBus dev.. I'm just the one who also keeps an eye on ibus)
The new behavior is changed to something like MAC, ctrl+space in ibus-1.5 now behave like alt+tab (kinds of stack based), most recent accessed is the next one being switched by ctrl+space.
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Fri, 14 Dec 2012 03:08:46 +0900, Fuminobu TAKEYAMA wrote:
Hello,
- ibus-* depending on ibus 1.5's typelib (developed in python) is
not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
Python is a dynamic language so we can see, for example, method missing error at runtime. latter one?
Looks so.
- Do we need to clean up its package's change log while it was
in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least.
So we need to merge the changelog, maybe with a bit of clean up.
The package of ibus-1.5 have been separately developed in M17N/Devel and not been submitted to Factory.
It has several change log entries for ibus-1.4.99.x. I think changes from 1.4 to 1.5 is not clear from the log but it is not so problematic: https://build.opensuse.org/package/view_file?expand=1&file=ibus.changes&package=ibus&project=M17N%3ADevel # Oh, it is not linked to M17N/ibus...
Then, yes, let's clean up M17N:Devel changelog. The development history in M17N:Devel isn't that important in this case.
- The released version still have something wrong.
For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
Maybe. We can add Zenkaku Hankaku key for Japanese by adding a file to /etc/dconf/profile but I don't know which binding is active. I'll try.
I think we should put all ibus-related packages into a clean sub-project and test them carefully before updating M17N/ibus.
Yes, let's put all ibus-related packages to M17N:Devel at first (just do branch or linkpac), then watch the build status.
Unfortunately, since we don't have any rules about M17N:Devel, it is not clean and has a lot of packages. # I cannot run zypper dup -r M17N:Devel
Shall we make a new subproject M17N:Testing like openSUSE:*:*:Testing for packages that should be merged into M17N soon?
I remember the similar topic raised up for mozc sometime ago in opensuse-ja ML :) I personally don't mind so much about creating a new sub project, but thinking twice, it doesn't have to be M17N:xxx at all but could be the personal one like home:yyy:ibus-test. What we need is a really a temporary test project that won't live long. Otherwise it'll be just the second M17N:Devel. (And basically testing here at this moment means checking mostly build breakage. The functional test is a different question.) If we care about the stability of M17N packages, it's the thing we need to reconsider. M17N project serves as the devel project of FACTORY, thus it should contain the latest packages to be merged to FACTORY. It conflicts with the development of new packages. In other words, if we'd like to keep stable packages, we should create the sub-project for that (e.g. M17N:stable), instead of creating yet another test sub-project.
Or clean up M17N:Devel?
Yes, this should be cleaned up in anyway, too. I think all scim updates should be merged to M17N / FACTORY sooner or later. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
(2012/12/14 16:47), Takashi Iwai wrote:
(And basically testing here at this moment means checking mostly build breakage. The functional test is a different question.)
What we are doing for ibus looks like functional test.
If we care about the stability of M17N packages, it's the thing we need to reconsider. M17N project serves as the devel project of FACTORY, thus it should contain the latest packages to be merged to FACTORY. It conflicts with the development of new packages.
I think stability of obs (including devel) projects will become more important. Actually many people use latest packages from those projects. This scenario is a benefit of our obs-style distribution development. Also I think to reduce factory team's workload, more careful review and test in devel project is needed. But if we need to submit developing packages to factory like KDE and GNOME, we have to separate stable/unstable packages as you say. Next is a technical topic. Can we use %posttrans in zypper or rewrite other tags? According to Fedora's spec [1], written by an upstream developer, we need:
%posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : glib-compile-schemas %{_datadir}/glib-2.0/schemas &>/dev/null || : dconf update
"dconf update" is especially important. It initializes database for ibus's configuration. Since our current package doesn't have this, it should not work correctly until we run "sudo dconf update" manually. We also need to add "dconf update" into %postun to remove the db.
# 'dconf update' sometimes does not update the db... dconf update if [ -f %{_sysconfdir}/dconf/db/ibus ] ; then rm -f %{_sysconfdir}/dconf/db/ibus fi
[1] http://pkgs.fedoraproject.org/cgit/ibus.git/tree/ibus.spec I have just added a patch from ibus's git head to fix ibus-setup crash. I guess ibus-1.5.2 will be released soon. -- Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Tue, 18 Dec 2012 03:01:29 +0900, Fuminobu TAKEYAMA wrote:
(2012/12/14 16:47), Takashi Iwai wrote:
(And basically testing here at this moment means checking mostly build breakage. The functional test is a different question.)
What we are doing for ibus looks like functional test.
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
If we care about the stability of M17N packages, it's the thing we need to reconsider. M17N project serves as the devel project of FACTORY, thus it should contain the latest packages to be merged to FACTORY. It conflicts with the development of new packages.
I think stability of obs (including devel) projects will become more important. Actually many people use latest packages from those projects. This scenario is a benefit of our obs-style distribution development. Also I think to reduce factory team's workload, more careful review and test in devel project is needed.
But if we need to submit developing packages to factory like KDE and GNOME, we have to separate stable/unstable packages as you say.
Yes, and it's been requested from GNOME people for long time, since the latest GNOME requires ibus-1.5. Currently, we have three level of packages: - M17N:Devel - M17N - openSUSE:Factory M17N:Devel is a place for development, supposed to be submitted to M17N later. Thus basically this should have been a place for build tests and package-level tests. M17N is the devel project of FACTORY, so this contains the package to be submitted to FACTORY. As seen here, there is no project dedicated for stability. That's the reason I proposed for M17N:Stable or whatever. And, the problem here is that we can't take M17N:Devel as the primary build/function test place. If M17N:Devel is more or less clean for ibus tests, everything is fine; then we can put branches or links of ibus-related package from M17N there. What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Next is a technical topic. Can we use %posttrans in zypper or rewrite other tags?
Yes, %posttrans is already used in many packages.
According to Fedora's spec [1], written by an upstream developer, we need:
%posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : glib-compile-schemas %{_datadir}/glib-2.0/schemas &>/dev/null || : dconf update
"dconf update" is especially important. It initializes database for ibus's configuration. Since our current package doesn't have this, it should not work correctly until we run "sudo dconf update" manually.
We also need to add "dconf update" into %postun to remove the db.
# 'dconf update' sometimes does not update the db... dconf update if [ -f %{_sysconfdir}/dconf/db/ibus ] ; then rm -f %{_sysconfdir}/dconf/db/ibus fi
[1] http://pkgs.fedoraproject.org/cgit/ibus.git/tree/ibus.spec
I have just added a patch from ibus's git head to fix ibus-setup crash. I guess ibus-1.5.2 will be released soon.
Great, thanks for your help! Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
(2012/12/18 16:35), Takashi Iwai wrote:
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
At least, hillwood and I have installed the ibus packages and been testing them to check whether they work as we expected.
What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Sorry, I put freetype2 git snapshot there. It should be removed.
Yes, %posttrans is already used in many packages.
On, I see. I will update the spec soon. Thanks, Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 19 Dec 2012 00:44:31 +0900, Fuminobu TAKEYAMA wrote:
(2012/12/18 16:35), Takashi Iwai wrote:
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
At least, hillwood and I have installed the ibus packages and been testing them to check whether they work as we expected.
That's good to hear. What I meant as build test is to simply test the builds of all (ibus-related) packages in a single project, e.g. M17N:Devel. It's a simple systematic test, just to make sure that it doesn't break any others. This could be done in M17N as well, if M17N isn't supposed to be a "stable" repo...
What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Sorry, I put freetype2 git snapshot there. It should be removed.
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right? Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
I removed it. Then, I could not add %posttrans to the spec file since hillwood's change contains %posttrans. https://build.opensuse.org/request/show/145762 Fuminobu TAKEYAMA (2012/12/19 1:05), Takashi Iwai wrote:
At Wed, 19 Dec 2012 00:44:31 +0900, Fuminobu TAKEYAMA wrote:
(2012/12/18 16:35), Takashi Iwai wrote:
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
At least, hillwood and I have installed the ibus packages and been testing them to check whether they work as we expected.
That's good to hear.
What I meant as build test is to simply test the builds of all (ibus-related) packages in a single project, e.g. M17N:Devel. It's a simple systematic test, just to make sure that it doesn't break any others. This could be done in M17N as well, if M17N isn't supposed to be a "stable" repo...
What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Sorry, I put freetype2 git snapshot there. It should be removed.
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 19 Dec 2012 02:30:20 +0900, Fuminobu TAKEYAMA wrote:
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
I removed it.
Then, I could not add %posttrans to the spec file since hillwood's change contains %posttrans. https://build.opensuse.org/request/show/145762
It looks like he removed dconf support in that SR. So, dconf update can be dropped as well, right? The rest, gtk-update-icon-cache and glib-compile-schemas would be still needed, though. thanks, Takashi
Fuminobu TAKEYAMA
(2012/12/19 1:05), Takashi Iwai wrote:
At Wed, 19 Dec 2012 00:44:31 +0900, Fuminobu TAKEYAMA wrote:
(2012/12/18 16:35), Takashi Iwai wrote:
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
At least, hillwood and I have installed the ibus packages and been testing them to check whether they work as we expected.
That's good to hear.
What I meant as build test is to simply test the builds of all (ibus-related) packages in a single project, e.g. M17N:Devel. It's a simple systematic test, just to make sure that it doesn't break any others. This could be done in M17N as well, if M17N isn't supposed to be a "stable" repo...
What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Sorry, I put freetype2 git snapshot there. It should be removed.
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi, Here is further test result of ibus 1.5: - IBus does not receive the Hankaku_Zenkaku key when IBus is launched by openSUSE's IM selector mechanism. It accept that key if I launch IBus after WM is started, for example, by running "ibus-daemon" from konsole, gnome-terminal, or launching it from /etc/xdg/autostart/ibus.desktop However, launching with the autostart mechanism may cause another problem. If applications to be launched by the autostart is clean, i.e. initial state, there is no problem. On my machine, WM always hangs up in several seconds after login like the problem of uim in GNOME 3. The following application was registered to the autostart: - Thunderbird - Hotot Qt - Dropbox, KFileBox but after I remove all of them and then add them again, this problem did not demonstrate. # maybe depending on the order to launch Fuminobu TAKEYAMA (2012/12/19 2:41), Takashi Iwai wrote:
At Wed, 19 Dec 2012 02:30:20 +0900, Fuminobu TAKEYAMA wrote:
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
I removed it.
Then, I could not add %posttrans to the spec file since hillwood's change contains %posttrans. https://build.opensuse.org/request/show/145762
It looks like he removed dconf support in that SR. So, dconf update can be dropped as well, right?
The rest, gtk-update-icon-cache and glib-compile-schemas would be still needed, though.
thanks,
Takashi
Fuminobu TAKEYAMA
(2012/12/19 1:05), Takashi Iwai wrote:
At Wed, 19 Dec 2012 00:44:31 +0900, Fuminobu TAKEYAMA wrote:
(2012/12/18 16:35), Takashi Iwai wrote:
Hm, does anyone already test coverage of all M17N packages with ibus upgrade? This is the first step as a migration, then we follow the functional test of the upgraded project.
At least, hillwood and I have installed the ibus packages and been testing them to check whether they work as we expected.
That's good to hear.
What I meant as build test is to simply test the builds of all (ibus-related) packages in a single project, e.g. M17N:Devel. It's a simple systematic test, just to make sure that it doesn't break any others. This could be done in M17N as well, if M17N isn't supposed to be a "stable" repo...
What's the actual breakage with M17N:Devel? I see freetype2 update, scim and fcitx updates. If any package updates in M17N:Devel aren't considered to be submitted to M17N at any time, such updates shouldn't be included in M17N:Devel as well.
Sorry, I put freetype2 git snapshot there. It should be removed.
Thanks. So, after removing it, we can just do "zypper dup" with M17N:Devel for testing the new ibus, right?
Takashi
-- Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
participants (3)
-
Fuminobu TAKEYAMA -
Takashi Iwai -
Weng Xuetian