[Summary]
MIR Team ack to this package.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: libmarisa0

Recommended TODOs:
- upstream provides tests in test/*, could those be enabled at build time?

[Duplication]
There is no other package in main providing the same functionality.
I mean obviously there are many data-structure helpers, but this one in
particular isn't available elsewhere. It is not a one-off just for
opencc, also librime and libkkc2 are using it which seems reasonable.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
   Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.0), libstdc++6 (>= 5.2)
- has libmarisa-dev which will be auto-promoted, but that has no deps
  other than libmarisa0 itself

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- there are some maintenance artifacts in the tarball, but none seems
  problematic and none goes into the binaries that we will promote.


[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does parse data formats and translate them into the data structures this
  provides. This would usually be done in the context of the user-input which
  doesn't sound like a very critical attach surface. OTOH I don't want to hear
  that e.g. all Ubuntu input boxes can be broken by a special input string or
  such. Therefore I think it is worth to pass this through a security review
  as well.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs as autopkgtest
- The package has a team bug subscriber (an intend-to-sub by the Desktop Team)
- no translation present, but this is not the Ui but a background feature
- not a python/go package, no extra constraints to consider in that regard

Problems:
- does not have a test suite that runs at build time
  But I think that is covered by the autopkgtests, never the less there is an
  upstream provided test collection, having that on build would be awesome.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place (the version we have synced from
  experimental contains it)
- d/watch is present and looks ok
- Upstream update history slow, but ok (seems more stable than a lack of attention)
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- Does not have Built-Using

Problems:
- d/rules isn't the cleanest, but nothing that would block this

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu or upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks