[MIR] mozc

[Aron Xu]

[Availability]
Currently in universe

[Rationale]
Mozc is a replacement candidate for Anthy, the previously default Japanese input method engine. It's an open source project originated from Google Japanese Input, and is widely considered superior than other candidates among the Japanese user community.

[Security: ]
CVE entries: none
Security history: none
Any binaries running as root or suid/sgid ? Any daemons ?
    -- all running as per user session, and /usr/bin/mozc-server may run as user daemon.
Network activity: does it open any port ? Does it handle incoming network data ?
    -- no, it doesn't
Does it directly (not through a library) process binary (video, audio, etc) or structured (PDF, etc) data ?
    -- no, it doesn't
Any source code review performed ? (The approver will do a quick and shallow check.)
    -- yes, no significant issue found.

[Quality Assurance]
Package works out of the box with no prompting.
There is no reproducible major bugs in Ubuntu and Debian.
Upstream is active, backed by Google.
Package is maintained at Debian, Ubuntu delta drops unwanted dependency for the ease of main inclusion and maintenance.

Upstream bug tracker: https://github.com/google/mozc/issues
Hardware: Does this package deal with hardware and if so how exotic is it ?
    -- no
Is there a test suite in the upstream source or packaging ? Is it enabled to run in the build ?
    -- yes, some fundamental tests

[UI standards]
    User-visible strings are internationalized using standard gettext system ?
        -- no, it's language-specific software requires the user knows Japanese
    Package with translatable strings builds a PO template during package build ?
        -- no
    End-user applications ship a desktop file?
        -- yes, for the engine settings panel.

[Standards Compliance]
FHS and Debian Policy compliant.
Packaging system (debhelper/cdbs/dbs) ? Patch system ? Any packaging oddities ?
    -- package is using debhelper.

[Maintenance]
Desktop Team will take care of them.

[Dependencies]
1. ninja-build: small build system closest in spirit to Make, and the package itself quite small and straight forward
2. zinnia: an online hand recognition system based on Support Vector Machines, processing the pen stroke
3. tegaki-zinnia-japanese: Japanese handwriting model for Zinnia, which is a data-only package

[Michael Terry (mterry)]

This is close to FF deadline. I'll look at these today, but you may need to prepare an FFe.

[Michael Terry (mterry)]

zinnia:
- Needs team bug subscriber for whomever will look after it in Ubuntu
- It's debug package seems built poorly (debug-file-with-no-debug-symbols). Not a blocker, but a point of concern.
- Has some tests (for our packaging, only relevant one is python/test.py), but they aren't designed as isolated unit tests, rather requiring a file that upstream has installed locally. :(

So needs a team bug subscriber and then it's OK. Not super thrilled with lack of tests, but what can ya do.

[Michael Terry (mterry)]

tegaki-zinnia-japanese:
- Sure, this is a tiny data package that hasn't changed in many years.
- But technically we still need a team bug subscriber for any bugs that come up.

[Michael Terry (mterry)]

Oy, another build system. I understand that we can't control what build system upstreams use, so we can't exclude it based on "we have enough build systems in main", but we have enough build systems in main. :)

This one seems poorly maintained in Ubuntu/Debian...
- Ubuntu only has 1.3, Debian has 1.5 (and neither has 1.6) -- merge request is bug 1473680
- Lintian warning package-installs-into-obsolete-dir for its bash completion files
- Lintian warning embedded-javascript-library about embedding jquery.js (don't do that! -- but actually, it's just in the documentation, I suppose that's not a blocker for main from a security point of view or really a maintenance POV)
- Build-Depends on obsolete hardening-wrapper and has copyright file syntax issues (both solved in Debian)
- Is maintained in Debian by one person, not a team. Not fully owned in Ubuntu either (though oxide team cares about it, but it's not clear they've committed to caring for it in Ubuntu)

What I'd like to see is a team commit to looking after it in Ubuntu (maybe that's ~oxide-developers, ask Chris Coulson). And, ideally a merge from Debian. Though maybe that's too much to ask at this late stage in wily.

[Michael Terry (mterry)]

(Looks like mozc can be passed a different generator than ninja via --gyp_generator. Could that be a way to skip depending on ninja? Though ninja is mostly fine, just curious.)

[Michael Terry (mterry)]

Ugh. gyp is also in universe.

[Aron Xu (happyaron)]

I've subscribed ~pkg-ime to all the packages, and if there's team that's more eager to take care of some packages (ninja-build, gyp) that's very welcomed.

mozc can use a different generator, but the Debian maintainer changed to use ninja-build in recent uploads, so I think it's better to follow instead of diverging too much. I'll follow up on the improvements of ninja-build later, it's looks not hard anyway.

[Michael Terry (mterry)]

OK, I've submitted our tiny delta for ninja-build to Debian. Hopefully we can get in sync next cycle and that will solve most of our maintenance concerns there. With a bug subscriber now, I'll approve.

[Michael Terry (mterry)]

For mozc, it looks OK. I'm assuming we don't need all the packages, like emacs-mozc, emacs-mozc-bin, or fcitx-mozc in main? Which do we actually need in main?

[Michael Terry (mterry)]

Oh wait. mozc should run tetss, probably like so: python build_mozc.py runtests

[Michael Terry (mterry)]

And for gyp..

- Doesn't seem super well maintained in Debian. Hasn't had a new snapshot of trunk in a couple years.
- It's debian/preinst should include #DEBHELPER#, but it doesn't really matter since debhelper wouldn't inject anything anyway. (actually, that whole file is a delta from Debian that could be dropped)

Blockers:
- It has tests but they aren't being run. "./gyptest.py -a" might do it, but I see test failures when I do that. So fixes might need to land as well.

[Ikuya Awashiro (ikuya-fruitsbasket)]

According to GYP Hacking [1], some preparation needed before the test running.
I think we don't mind for the test failure.

[1]: https://chromium.googlesource.com/external/gyp/+/HEAD/docs/Hacking.md

[Michael Terry (mterry)]

Which preparation? The depot_tools? Aside from pylint, looks like it's mostly git/svn helpers.

I don't mind us saying "these test failures don't matter" as long as we've actually investigated why they're failing and can say that it's not a "real" failure. But I don't think we've done that here.

[Aron Xu (happyaron)]

Uploaded mozc with test case being run. Will investigate gyp test failures shortly.

[Michael Terry (mterry)]

Question about mozc still stands though: "I'm assuming we don't need all the packages, like emacs-mozc, emacs-mozc-bin, or fcitx-mozc in main? Which do we actually need in main?"

[Aron Xu (happyaron)]

mozc-* and fcitx-mozc are needed to be in main at the moment.

[Ikuya Awashiro (ikuya-fruitsbasket)]

BTW, fcitx-mozc is not installed by default on Ubuntu 15.10.
If the mozc is in main, is it such an issue fixed ? or another issue?

[Aron Xu (happyaron)]

No, it won't because fcitx-mozc is not seeded in the image, but it's pulled by language-selector when installing complete language support for Japanese (which is current). If you have a Japanese remix and seed that in the image, then that's automatic.

[Ikuya Awashiro (ikuya-fruitsbasket)]

Hi Aron, thanks for your comment.
I will file an another issue.

[Ikuya Awashiro (ikuya-fruitsbasket)]

I've done it.
https://bugs.launchpad.net/bugs/1506502

[Adam Conrad (adconrad)]

I promoted gyp, I'm not terribly concerned about the tests not being run for a build suite that we already ship a dozen times embedded in several other sources.