[Pkg-utopia-maintainers] Bug#816156: Python dbus Attribute error

[Simon McVittie]

On Tue, 01 Mar 2016 at 19:28:07 -0600, Daniel Peterson wrote:
> I am trying to run the onscreen keyboard onboard with python, and dbus
> complains. Onboard runs with python3.4 by default. Running it with python3.5
> appears to fix the problem. Trying to import dbus.exceptions with python3.4
> will cause the problem I was seeing earlier. 

This is somewhat expected. Debian stretch is currently in the middle of a
transition that will remove Python 3.4 as a supported version:
<https://release.debian.org/transitions/html/python3.4-rm.html>

Specifically, /usr/bin/python3 was set to python3.5 (previously python3.4)
in January: https://tracker.debian.org/news/739853

and 3.4 was removed from the list of supported versions on 22nd February:
https://tracker.debian.org/news/749899

All Python modules in Debian are compiled with support for whatever the
supported versions happened to be when they were built. Python modules
whose list of supported versions does not match the canonical list set by
the Python maintainer will be rebuilt by the release team at some point.

In the case of python3-dbus, because I uploaded it the same day that the
Python maintainers changed the supported versions, you can see from its
packages page that it was built with support for 3.4 and 3.5 on amd64
(that build started before the new python3-defaults package was available),
but with support for only 3.5 on all other release architectures:
https://packages.debian.org/unstable/python3-dbus
https://packages.debian.org/experimental/python3-dbus
(look for "dep: python3")

> ImportError: No module named '_dbus_bindings'

This is the compiled C part of python3-dbus, which needs to be built
once per supported version of Python.

> I will also file a bug against onboard so that others know to move up to a
> newer python version. 

According to <https://packages.debian.org/unstable/onboard>, onboard
was built with python3.4 as the default Python 3 on all release
architectures. It just needs a recompile, which will be scheduled by
the release team at the appropriate time; the package's maintainer is
not usually involved in this process.

Any upload by the onboard maintainer will fix this as a side-effect,
but the onboard maintainer should *not* normally do an upload just
to fix this, because if everyone did that we'd have several hundred
uncoordinated uploads, not necessarily in the right order.

However, I'm surprised that there wasn't a mass-rebuild of packages that
depend on a single Python 3 version (such as onboard) so that they all
use python3.5, *before* removing python3.4 as supported. Perhaps something
has gone wrong with this particular transition and a step was missed.

    S