[MIR] ibus-libpinyin dependencies

Bug #1909665 reported by Gunnar Hjalmarsson on 2020-12-30

This bug report will be marked for expiration in 53 days if no further activity occurs. (find out why)

This bug affects 1 person
Affects Status Importance Assigned to Milestone
lua5.4 (Ubuntu)
opencc (Ubuntu)

Bug Description

Please include these packages in Ubuntu's component main:

* lua5.4
* opencc

ibus-libpinyin provides the default method for inputting simplified Chinese, and is shipped with the desktop ISO. The latest Debian version of ibus-libpinyin couldn't migrate in hirsute, though, since it depends on liblua5.4-0 and libopencc1.1 which are both in universe.

For now I built ibus-libpinyin in Ubuntu with lua5.3 and without opencc support. However, it would be preferable to be able to sync the fully featured package from Debian.

lua5.2 and lua5.3 are already in main. opencc is a library for converting characters between traditional Chinese and simplified Chinese, and has been in main previously (trusty).

As regards bug subscribing, I assume that ~ubuntu-server is a suitable candidate for lua5.4 and that ~desktop-packages should be subscribed to opencc bugs.

Bugs lua5.4
There are no open bugs in version 5.4.2

Bugs opencc


No open Debian bugs.

I have read


and haven't found any issues that would prevent the proposed main inclusion.

Changed in lua5.4 (Ubuntu):
assignee: nobody → Christian Ehrhardt  (paelzer)
Changed in opencc (Ubuntu):
assignee: nobody → Didier Roche (didrocks)

Generally the server-team would be ok with Lua5.4 - but we need to avoid adding more and more versions concurrently.

For older Lua versions being held in main I found:
- apache2-bin depends on lua5.2
- dovecot depends depends on lua5.3

If those two could move to lua5.4 we could have "just one" lua version supported.
It seems that isn't too trivial as it took time to get 5.1 dropped (bug 1324062).
And we currently have 5.2/5.3 in main at the same time.

Vice versa as long as the servers that made us support lua5.[23] can't move on to a new version I'd prefer to stick to lua5.3 which (thanks to Gunnar) right now works fine in ibus-libpinyin.

I filed a bug 1910372 against apache2/dovecot for it to get rid of 5.2 at least.
And to (further down the road) we can jointly move to 5.4 later.

For ibus-libpinyin I'd ask to keep it at lua5.3 as it is now until bug 1910372 is resolved to the extend that we know if apache2/dovecot will be able to move to 5.4 sometime soon (<=22.04 for example)

Changed in lua5.4 (Ubuntu):
assignee: Christian Ehrhardt  (paelzer) → nobody
status: New → Incomplete
Didier Roche (didrocks) wrote :
Download full text (4.6 KiB)

On opencc, some small stuff to discuss/fix before getting the finale ACK on it.
It would be great to have the list of binary packages tha needs to be promoted to main.

Required TODOs:
TODO - talk with the debian team about the lintian warnings from the -doc package, where the html doc seems to fetch images from the Internet which is a privacy breakage (reading offline doc shouldn’t require Internet). I may have missed an escape in the tag, but in that case, please place a lintian override then. See "Packaging red flags" problem section for more details.
TODO: talk with the debian team to replace the shlibs file by a symbol one to have symbol tracking.
TODO: 2 warnings during build, one minor, one a little bit more annoying. Please reach upstream to get those fixed. More details in "Upstream red flags" / problems section.
TODO: get Seb aggreeing that the desktop team is the correct team to maintain it and subscribing desktop-packages to it.

There is no other package in main providing the same functionality.

- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
- some embedded source code present, however, this is devendorized at built time: jquery, marisa, rapidjson… and linked to the system ones (mostly js stuff for documentation)
- no static linking

- 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 parse data formats to convert to another form, but was previously in main and is using a limited known set
- 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)

[Common blockers]
- does not FTBFS currently
TODO: - does have a test suite that runs at build time
- no translation present, but none needed for this case
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency

- there is no test suite which would have been good for such a program. Not a blocker though as it was already in main.
- Waiting on seb’s answer for the desktop team to take ownership of it as part of the new promotion.

[Packaging red flags]
- Ubuntu does not carry a delta
- d/watch is present and looks ok
- Upstream update history is sporadic
- Debian/Ubuntu update history is good
- the current release is packaged + snapshotted since mid-2020 (no new release so far and some fixes seemed to be wanted by the debian packaging team)
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings, but some needs checking (see below)
- d/rules is rather clean
- Does not have Built-Using

- no symbol tracking, only a shlibs file.
- the -doc usr/share/doc/opencc/html/index.html package seems to fetch multiple images and svg objects from the web:
<img src="https://opencc.byvoid.com/img/opencc.png" alt="opencc" class="inline"/>
<object type="image/svg+xml" data="https://github.c...


Changed in opencc (Ubuntu):
status: New → Incomplete
assignee: Didier Roche (didrocks) → nobody
Sebastien Bacher (seb128) wrote :

> TODO: get Seb aggreeing that the desktop team is the correct team to maintain it and subscribing desktop-packages to it.

I'm not familiar with the details of why opencc is needed and what we would loose while building without it but it seems it should be ok to maintain so if that's the recommended way it's fine to subscribe desktop-packages do the source, doing that now

Gunnar Hjalmarsson (gunnarhj) wrote :

Understood, Christian, and even if it's more convenient to sync, the delta due to lua5.3 instead of 5.4 (for now) is trivial and doesn't affect usability AFAIK.

Is there anything you expect me to do wrt lua? If not, I suppose the status of that bug task should be changed to something else but "Incomplete".

Thanks for your review, Didier! I'm thinking I can file an upstream bug report about the build warnings and look into the symbol tracking thing (need to read up on the latter topic).

As regards remote images I see two of those right before the "Introduction" header and one right after. If browsing off line those images are replaced with text labels. Do you think that would motivate a Debian patch to fix?

@Sebastien: Neither I am able to tell exactly which functionally opencc adds to ibus-libpinyin. Don't input traditional and simplified Chinese simultaneously often. :) If you like, I can ask somebody in the IME team to clarify.

Gunnar Hjalmarsson (gunnarhj) wrote :


On 2021-01-12 11:54, Gunnar Hjalmarsson wrote:
> As regards remote images I see two of those right before the
> "Introduction" header and one right after. If browsing off line
> those images are replaced with text labels. Do you think that would
> motivate a Debian patch to fix?

It may be worth mentioning that libopencc-doc is only a "Suggests" in the opencc package.

The only binaries which need to be promoted to main due to ibus-libpinyin are:


Hi Gunnar,
no action needed for now for lua.
We will keep ibus-libpinyin depend on lua5.3 (as it is right now) and therefore the lua5.4 task here does not need to be handled.

OTOH we have already a change in the queue to get apache2 onto lua5.3 as well so that we end up with "just one lua version".

Down the road once more/all deps are lua5.4 ready we might then move all as one.

Changed in lua5.4 (Ubuntu):
status: Incomplete → Won't Fix
Didier Roche (didrocks) wrote :

@Gunnar: I suggest opening the bug upstream about the build warnings, indeed and maybe about the -doc files

Then, if you can get things fixed on the debian side (symbol tracking) + patching the -doc files. Indeed, if you are online, then, there is the privacy breakage (hence the lintian warning). I would be ok then to ACK this new version once in proposed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers