[MIR] ibus-libpinyin dependencies

[Gunnar Hjalmarsson]

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
-----------
https://github.com/byvoid/opencc/issues

https://bugs.launchpad.net/ubuntu/+source/opencc

No open Debian bugs.

I have read

https://wiki.ubuntu.com/MainInclusionProcess#Main_Inclusion_requirements

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

[Christian Ehrhardt  (paelzer)]

Hi,
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)

[Didier Roche-Tolomelli (didrocks)]

Hey.
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.

Notes:
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.

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

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

[Embedded sources and static linking]
OK:
- 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

[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 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]
OK:
- 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

Problems:
- 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]
OK:
- 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

Problems:
- 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...

[Sebastien Bacher (seb128)]

> 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)]

lua5.4
------
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".

opencc
------
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)]

@Didier:

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:

libopencc1.1
libopencc-data

[Christian Ehrhardt  (paelzer)]

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.

[Didier Roche-Tolomelli (didrocks)]

@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.

[Gunnar Hjalmarsson (gunnarhj)]

@Didier: The opencc docs file is now patched, and there is a symbols file at last which allows building on all the architectures.

https://launchpad.net/ubuntu/+source/opencc/1.1.1+git20200624+ds2-4ubuntu1

The build warnings have been reported upstream:

https://github.com/BYVoid/OpenCC/issues/551

Hopefully that's it for the MIR.

However, as regards the symbols file the solution is not ideal. We tweak the symbols file for Ubuntu, since s390x seems to differ between Debian and Ubuntu (bug #1912882). Great if you have an idea how to get back in sync with Debian. This is the delta ATM:

https://launchpadlibrarian.net/519531769/opencc_1.1.1+git20200624+ds2-4_1.1.1+git20200624+ds2-4ubuntu1.diff.gz

[Didier Roche-Tolomelli (didrocks)]

This looks good, thanks Gunnar! On that note, acking the MIR and promoting right now to hirsute.

To keep in sync with Debian, what I would suggest is to create alongside <package>.symbols, a <package>.ubuntu.symbols. Then replace it at build time (and restore it afterwards) in debian/rules, so that the right version (upstream or ubuntu) is in place during build, making sense?

[Didier Roche-Tolomelli (didrocks)]

libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute amd64: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute arm64: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute armhf: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute i386: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute ppc64el: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute riscv64: universe/libs/optional/100% -> main
libopencc1.1 1.1.1+git20200624+ds2-4ubuntu1 in hirsute s390x: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute amd64: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute arm64: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute armhf: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute i386: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute ppc64el: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute riscv64: universe/libs/optional/100% -> main
libopencc-data 1.1.1+git20200624+ds2-4ubuntu1 in hirsute s390x: universe/libs/optional/100% -> main
opencc 1.1.1+git20200624+ds2-4ubuntu1 in hirsute: universe/libs -> main

[Gunnar Hjalmarsson (gunnarhj)]

On 2021-01-26 08:01, Didier Roche wrote:
> To keep in sync with Debian, what I would suggest is to create
> alongside <package>.symbols, a <package>.ubuntu.symbols. Then
> replace it at build time (and restore it afterwards) in debian/rules,
> so that the right version (upstream or ubuntu) is in place during
> build, making sense?

That would be doable and does make sense. Thanks!

Yesterday I made a few awkward attempts to use the "(optional)" prefix for some MISSING symbols, but failed to get it off the ground. Maybe it's me or maybe that approach doesn't fit well in this case.

[Christian Ehrhardt  (paelzer)]

As per the discussion on
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1910372/comments/9

We should down the road consider and recheck if we can move all to 5.4 then.
I'll re-open the task, but since it isn't waiting on the MIR Team as "incomplete" for now.

Next steps (suggested):
- Evaluate lua using programs if now we could move them all to 5.4. If not file upstream issues (this could be done in 22.04).
- Then later once those hopefully resolved (>=22.10) one could do the actual change to packages.

Anyone can step up to start tackling those steps. So far this is just a bit of help for getting this into the right path, not a commitment.

[Bryce Harrington (bryce)]

I've uploaded dovecot 2.3.19, which comes from Debian ready for building with lua5.4. I downgraded it to lua5.3 since that's our current standard, but if/when we want to proceed with lua5.4, dovecot is good to go.

apache2 is also ready for lua5.4. I'm not sure of the state of opencc though, and expect there are going to be other packages not yet identified with some version dependence. For that reason, server team feels the ideal time to MIR lua5.4 will be at the opening of the 23.04 development cycle (so, Oct/Nov).

[Gunnar Hjalmarsson (gunnarhj)]

On 2022-08-12 20:48, Bryce Harrington wrote:
> I'm not sure of the state of opencc though,

It's ibus-libpinyin which build-depends and depends on lua, not opencc, and AFAIK it's fine. It has been built with lua5.4 on Debian all since this bug report was submitted.

To avoid an issue on the armel architecture, Debian builds ibus-libpinyin without lua on armel, but that shouldn't affect us.

[Gunnar Hjalmarsson (gunnarhj)]

Closing this now, see bug #2026608.