GNOME Bugzilla – Bug 775768
--enable-introspection build broken if pygobject for python2 is not installed
Last modified: 2016-12-16 08:15:48 UTC
Created attachment 341577 [details] configure output In GNOME we don't have any python2 anymore, but the NetworkManager configure script still depends on it. See attached configure output. pygobject (for python3) is already installed by JHBuild as a dependency of NetworkManager, and working fine, but NetworkManager's configure check is wrong because it always uses python2. I thought that to fix it, we could switch it to use python3, or do something more complicated like using AM_PYTHON_PATH3. But unfortunately the configure check is not right, because generate-settings-docs.py really does need python2. GNOME really needs NetworkManager introspection else we cannot have nice things like "gnome-shell", so to fix this without bringing back python2 (ignore the irony that jhbuild itself depends on python2 ;) I'm going to make NetworkManager 1.2 a system dependency for now. It means a 6-12 month lag before GNOME can depend on new NetworkManager features until this is fixed. Sorry, JHBuild is not great. :(
Sounds like the right fix is to support both python2 and 3 *sigh*. See also: https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00006.html
Another related issue is that currently the XSLTPROC and PERL variables (set at this point in the configure script) both get set to "no" if they're not found, which make will try to execute.
(In reply to Michael Catanzaro from comment #0) > I'm going to > make NetworkManager 1.2 a system dependency for now. In the end it was easier to use a release tarball. When this is fixed, you can revert https://git.gnome.org/browse/jhbuild/commit/?id=049bea9ab6fc54f1710078619b70910f7774602a
AFAIS, building NM with python3 works fine. But for that, you need that the "python" in your $PATH points to python3. Note that the "python" name is hardcoded: libnm/generate-setting-docs.py:#!/usr/bin/env python http://legacy.python.org/dev/peps/pep-0394/ > In order to tolerate differences across platforms, all new code that needs > to invoke the Python interpreter should not specify python, but rather > should specify either python2 or python3 (or the more specific python2.x and > python3.x versions; > One exception to this is scripts that are deliberately written to be source > compatible with both Python 2.x and 3.x. Such scripts may continue to use > python on their shebang line without affecting their portability. Note that these are build-requirements for NM. To build NM, you need a working python+pyobject, provided by "/usr/bin/env python". Of course, there is also: > for the time being, all distributions should ensure that python refers to > the same target as python2. > however, end users should be aware that python refers to python3 on at > least Arch Linux (that change is what prompted the creation of this PEP), > so python should be used in the shebang line only for scripts that are > source compatible with both Python 2 and 3. I think this is not a bug.
(In reply to Thomas Haller from comment #4) > AFAIS, building NM with python3 works fine. > > But for that, you need that the "python" in your $PATH points to python3. Of course that's not the case for the distributions that we support (Fedora, Ubuntu). Could we just change it to explicitly use python3 instead? > Note that these are build-requirements for NM. To build NM, you need a > working python+pyobject, provided by "/usr/bin/env python". Since we've removed python2-pygobject as a dependency of GNOME, and don't want to bring it back, we don't want to fulfill this requirement. > I think this is not a bug. That's unfortunate. Ideally the dependency on python2-pygobject would be removed so that we can revert [1] and undo the downgrade that caused in [2]. [1] https://git.gnome.org/browse/jhbuild/commit/?id=049bea9ab6fc54f1710078619b70910f7774602a [2] http://ftp-nyc.osuosl.org/pub/gnome/core/3.23/3.23.3/NEWS
To summarize the issue: to build NM you need either: a) with `python --version` giving you 2.x "python-gobject-base" package installed b) with `python --version` giving you 3.x python3-gobject-base package installed But currently there is no way to enforce using say python3, if you `which python` is a symlink to python2 binary.
ok, should be fix now with https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6070fe697a4ccf9c90817f6d7268ba184fc744ea Note, that you have to explicitly select the python interpreter during ./configure. For example PYTHON=python3 should work. Michael, how does that look? Closing, please reopen if something is missing.
Thanks, it looks sane. I'll test it soon.
Now configure does find python3 successfully, but the build scripts are still using python2 so they don't work. If you want to use AM_PATH_PYTHON you really have to actually use the @PYTHON@ variable in the shebang, replace the executable scripts with .in files, and generate them at configure time by listing them AC_CONFIG_FILES.
Oh, I see your patch already attempted to address that for generate-setting-docs.py, and in a nicer way. You just missed a spot.
Created attachment 342047 [details] [review] build: always use the right python for generate-settings-docs.py
(In reply to Michael Catanzaro from comment #11) > Created attachment 342047 [details] [review] [review] > build: always use the right python for generate-settings-docs.py this is right. Merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4b6fb82bc57b193253b8264ac7b74d60aec9d582 Thanks for the patch!