Comment 9 for bug 1356222

Revision history for this message
Aron Xu (happyaron) wrote : Re: [Bug 1356222] Re: [MIR] fcitx and related packages

On Mon, Jan 12, 2015 at 11:27 PM, Didier Roche <email address hidden> wrote:

> General comment: why resetting fcitx-hangul, fcitx-m17n, fcitx-
> sunpinyin and fcitx-table-extra from incomplete to confirmed? Seems that
> no release to fix the blockers have been uploaded, so previous state
> remains the same. Please get an upstream release and an upload to ubuntu
> to fix the blockers before turning that state.
>
> ---
>
> -> fcitx:
> * NEEDS FIXING: transitional packages like fcitx-libs-gclient,
> fcitx-libs-qt and fcitx-libs:
> - please remove the whole description stenza in debian/control and use a
> snippet like in https://wiki.debian.org/Renaming_a_Package (Method 2):
> Description: transitional dummy package
> This is a transitional dummy package. It can safely be removed.
> This will avoid puzzling the users between the 2 packages if they are
> equivalent (which seems to be the case, as they just depends on the other
> package).
> - its section should be oldlibs
> - also, please update the recommends/depends from other package (they
> still depend on the transitional package): fcitx-libs: Recommends:
> fcitx-libs-gclient (>= ${source:Version}). It should be on
> libfcitx-gclient0.
>
>
Fixed.

> * NEEDS FIXING: I guess the autostart binary (in fcitx-bin) shouldn't be
> in usr/bin, but more in an exec path like libexec for instance. You told
> upstream liked the idea, any news since september for a release with
> this? I would prefer that we don't pulling the user PATH with autostart
> content.
>
>
Upstream changed their mind because they think it's a tool that can be used
to detect whether fcitx is running already, and they don't think renaming
it useful. Can we keep it there?

> * NEEDS INFO: IIRC, you told me that the .conf and .mk in fcitx-table-*
> packages are arch dependent (they are shipped in arch-dependent package
> anyway). If this is the case, they shouldn't be installed in usr/share
> as it's a policy violation and should rather be in libexec.
>
>
Fixed. They are not arch-dependent anymore, it now uses little-endian
across all platform. I've moved those files to arch:all and added
version-ed dependency to fcitx-table.

>
> -> fcitx-anthy:
> * MINOR: debian/copyright miss some more fixes:
> src/preedit.cpp: Copyright: 2004-2005 Takuro Ashie / 2012 CSSlayer
> src/action.*: miss Copyright: 2012 CSSlayer
>
>
Fixed.

> ---
>
> -> fcitx-hangul
> 2 issues fixed in debian git, but no upload for this yet since september.
> Needs an ubuntu upload for this:
> * The package is multi-arch and should be marked as such in debian/control
> (
> http://anonscm.debian.org/cgit/pkg-ime/fcitx-hangul.git/commit/?id=0d4418f3a35e1346f6c4461d3eb5d97016e4f002
> )
> * missing Copyright: 2012 CSSlayer <email address hidden> -> should be
> 2010-2012 (
> http://anonscm.debian.org/cgit/pkg-ime/fcitx-hangul.git/commit/?id=648c746466c92d6b9a86a5d4bcade691e57b2f86
> )
>
>
Fixed.

> ---
>
> -> fcitx-m17n:
> 2 issues fixed in debian git, but no upload for this yet since september.
> Needs an ubuntu upload for this:
> * The package is multi-arch and should be marked as such in debian/control
> (
> http://anonscm.debian.org/cgit/pkg-ime/fcitx-m17n.git/commit/?id=15108dfe41f329f4bb041ca96f2dbebda117ec24
> )
> * missing Copyright: 1995-1997 Peter Mattis, Spencer Kimball and Josh
> MacDonald in im/keysymname.c (
> http://anonscm.debian.org/cgit/pkg-ime/fcitx-
> >>> m17n.git/commit/?id=9d981e902b048bc3cdb74d94b15ab896ae8029da)
>
>
Fixed.

> ---
>
> -> fcitx-qimpanel:
> * NEEDS FIXING: I guess the autostart binary shouldn't be in usr/bin, but
> more in an exec path like libexec for instance. You told upstream liked the
> idea, any news since september for a release with this? I would prefer that
> we don't pulling the user PATH with autostart content.
>
>
Fixed.

> ---
>
> -> fcitx-qt5:
> * BLOCKER: Still no release with the COPYING for GPL2 nor LGPL2. Both are
> needed to be shipped upstream in a release that we package in ubuntu (
> https://github.com/fcitx/fcitx-qt5/issues/4).
>
>
New upstream release does not have LGPL code anymore, thus not a problem
now.

> * NEEDS INFO: it seems that fcitx-libs-qt5 and fcitx-libs-qt5-dev are now
> just transitional packages, right (it's empty, have the dep/recommends
> similar to the replacing package)? If so, please remove the whole
> description stenza and use a snippet like in
> https://wiki.debian.org/Renaming_a_Package (Method 2):
> Description: transitional dummy package
> This is a transitional dummy package. It can safely be removed.
> and Section: oldlibs
> Also, the Breaks/Replaces should be versioned.
> This will avoid puzzling the users between the 2 packages if they are
> equivalent (which seems to be the case, as they just depends on the other
> package).
>
>
Fixed.

>
> ---
>
> -> fcitx-sunpinyin:
> * previous copyright BLOCKERS in debian git, but no upload since.
>
>
Fixed.

> ---
>
> -> fcitx-table-extra:
> * BLOCKER: tables/scj6.txt is GPL3, there is no COPYING file mentionning
> GPL3. You need upstream to ship it.
> -> Still waiting for a release (https://github.com/fcitx/fcitx/issues/170)
> with the fixed version
>
>
Released.

> * BLOCKER (was a NEEDS FIXING and turning as a BLOCKER now with gtk3 not
> doing the scaling anymore for you, like in unity dash):
> W: fcitx-table-cantonese: icon-size-and-directory-name-mismatch
> usr/share/icons/hicolor/64x64/apps/fcitx-cantonese.png 48x48
> W: fcitx-table-stroke5: icon-size-and-directory-name-mismatch
> usr/share/icons/hicolor/64x64/apps/fcitx-stroke5.png 48x48
> W: fcitx-table-zhengma: icon-size-and-directory-name-mismatch
> usr/share/icons/hicolor/48x48/apps/fcitx-zhengma.png 64x64
>
>
Fixed.

> * NEEDS FIXING: debian/rules:
> Mind adding a small comment in debian/rules as in -other explaining the
> reason of stripping the .mo file
>
>
Fixed.

> ---
>
> -> libgooglepinyin:
> * NEEDS FIXING: FTBFS on armhf, i386 and powerpc
>
>
Fixed.

>
> -> presage:
> * MINOR: any reason why presage priority is extra?
> * NEEDS INFO: will python-presage be used? If so, it needs to be a python3
> package in addition to the current python2 one as we now have main almost
> fully supporting python3. Also, please not that this binary package (if put
> in main) depends on python-wxgtk2.8, not in main.
>
>
Only libpresage1 is used, other stuff like python bindings and executables
aren't. So we can only prompt the library to main and keep others in
universe.

For priority I don't know the reason, it was written by its Debian
maintainer.

> ---
>
> -> tinyxml:
> * NEEDS INFO: We already have multiple xml libraries in main. Any chance
> to switch the build-dep on that one to another one, like the boost lib?
> (was already asked, but didn't get an answer if I'm right on that one)
> Otherwise, the package itself is fine, status depending on the above
> answer.
>
>
Answer is that presage is almost in a maintenance only status, changing XML
library is not desired.

>
> ----
> On a final note, can you ensure that all those packages have the desktop
> bug team as a suscriber for tracking them?
>

~fcitx-team has subscribed to all the packages.