Re: IBus 1.5

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: [email protected]
To contact the owner, e-mail: [email protected]