FS#65410 - [ibus] misplaced and missing python files

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Friday, 07 February 2020, 16:17 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 02 May 2023, 21:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Skimming through the package shows:
- python files (python2 and/or python3) in multiple places a) /usr/lib/python2.7/site-packages and b) /usr/share/ibus/setup
- ibus(-setup) seemingly supports both python2 and python3, yet
- the files in a) have only python2 cache, while the ones in b) only python3 cache

As a result, trying to run ibus-setup with either python2 or 3, can be sluggish since:
- only a subset of the python cache is missing, and
- python itself will try to create the cache ... only to fail as the locations are RO for normal users :-(


Although I'm not a python wizard, my understanding is that:
- python files should be in their respective site-packages [1] location, and
- the cache (.pyc or .pyo) should be in alongside the respective files

For example, the libibus package already does this by the book.

[1] https://wiki.archlinux.org/index.php/Python_package_guidelines
This task depends upon

Closed by  Toolybird (Toolybird)
Tuesday, 02 May 2023, 21:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  "See my last comment - all the relevant issues are fixed. The remainder is an upstream decision."
Comment by Emil (xexaxo) - Friday, 07 February 2020, 18:14 GMT
Quick example on the python2 side. For python3 things are similar, albeit for different files.

$ export PYTHON=python2
$ timeout 5s strace ibus-setup |& grep ibus.*pyc.*ACCES
openat(AT_FDCWD, "/usr/share/ibus/setup/i18n.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/keyboardshortcut.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/emojilang.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/icon.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/enginecombobox.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/enginedialog.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/enginetreeview.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/ibus/setup/engineabout.pyc", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0100644) = -1 EACCES (Permission denied)

Comment by loqs (loqs) - Friday, 02 October 2020, 21:30 GMT
@xexaxo if you build ibus with the diff from [1] applied are there any missing python3 .pyc files?

[1] https://bugs.archlinux.org/task/62995#comment193086
Comment by Emil (xexaxo) - Thursday, 08 October 2020, 15:00 GMT
@loqs I suspect you're talking about the "remove python2 support" patch out of the 4?
And yes, since there's no more python2 support ... there's no point in having python2 cache ;-)

There's a few things to consider here:
- ideally, just removing python2 support (in Arch's packaging of course)
- moving the python3 files b) as per the guidelines [1]
- generating and shipping the python3 cache files
Comment by loqs (loqs) - Thursday, 08 October 2020, 17:28 GMT
@xexaxo the following is from the strace with the diff I suggested applied.
The cache files are provided and accessed by ibus-setup. Can you not reproduce this with my PKGBUILD?

openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/i18n.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/keyboardshortcut.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/emojilang.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/icon.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/enginecombobox.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/enginedialog.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/enginetreeview.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
openat(AT_FDCWD, "/usr/share/ibus/setup/__pycache__/engineabout.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 10
Comment by Emil (xexaxo) - Friday, 09 October 2020, 10:39 GMT
There are 4 diffs in the mentioned link, and I don't know which one you're talking about :-(

Looking closer - it seems like the last argument (missing python3 cache) has been resolved in the upstream package for a while.
Comment by loqs (loqs) - Friday, 09 October 2020, 13:07 GMT
The diff shows the changes. The src tarball is for easy building.

There are two diffs for ibus in the link I provided as ibus no longer builds after vala was updated to version 50 so I had to updated it.
The other diffs of the four are for ibus-pinyin and sunpinyin to change those packages to python3.
Comment by Emil (xexaxo) - Friday, 09 October 2020, 15:13 GMT
Please note that I've been using local hacks for months.
I'm more than happy to share them and continue as-is, until the maintainer speaks up on any of the ibus/python2 issues.

That said, the `rm -rf ...python2.7` hunk in your patch indicates that you're _not_ building in clean chroot.

In other words: personally, I'm good thanks. if you can awaken the maintainer that'll be amazing.
Comment by loqs (loqs) - Friday, 09 October 2020, 16:25 GMT
You mean this hunk

@@ -54,7 +53,6 @@ package_ibus() {
make DESTDIR="$pkgdir" install
make -C src DESTDIR="$pkgdir" uninstall
make -C bindings DESTDIR="$pkgdir" uninstall
- rm -r "$pkgdir"/usr/lib/python2.7/site-packages/gi # compiled pyc/pyo files were not cleaned
make DESTDIR="$pkgdir" uninstall-pkgconfigDATA
}

that removes the rm -r line from the current PKGBUILD?

The PKGBUILD was built in a clean chroot and without that change fails because the directory does not exist after the removal of python2 support.
Comment by Emil (xexaxo) - Monday, 12 October 2020, 08:05 GMT
You are correct - I've misread it as +. /me hides in shame ;-)
Comment by Emil (xexaxo) - Tuesday, 02 May 2023, 14:06 GMT
Having a look at recently - I think we can close this.

- the python2 stuff is gone - separate issue, fixed already
- the package contains (optimised or nor) python3 bytecode
- the files are installed in "weird" location, but that's upstream decision not ours

Loading...