Created attachment 3666 [details] failure log gpgme's task do_configure fails with curent master (9fe7a69), it fails with the current error: configure: error: cannot import Python module "distutils". Please check your Python installation. The error was: readline: /etc/inputrc: line 19: term: unknown variable name
Humberto tried to reproduce it and he wasn't able to.
Just checked, works fine for me too. I'd say it's probably a problem with your setup.
(In reply to comment #2) > Just checked, works fine for me too. I'd say it's probably a problem with > your setup. I cloned a new poky repository, and tried to build a core-image-minimal without changing anything in the configuration (had to fetch everything and no sstates were used), I got the same error. I haven't modified any of the system tools and it was working fine a week ago. Also, this happens only with python3, if gpgme is build for python2 or only for cpp, this error doesn't appear.
*Host* setup. I bet the difference is whether you have python3-distutils installed on the host.
The relevant bit of configure: AC_MSG_CHECKING([for the distutils Python package]) ac_distutils_result=`$PYTHON -c "import distutils" 2>&1` if test -z "$ac_distutils_result"; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) Does running the host python produce the same warnings? I'm wondering whether you're running something like Arch and the inputrc is incompatible with the readline in the native sysroot.
I found the problem, the problem is with readline and the /etc/inputrc file. I discarded this at the beginning because another build with the same setup was successful. I'm using opensuse 42.2 and /etc/inputrc has this problematic line: "set term xy". Once commented the build success. The very very odd thing is that other Jose also did a build in opensuse with the same line and it was successful.
(In reply to comment #5) > The relevant bit of configure: > > AC_MSG_CHECKING([for the distutils Python package]) > ac_distutils_result=`$PYTHON -c "import distutils" 2>&1` > if test -z "$ac_distutils_result"; then > AC_MSG_RESULT([yes]) > else > AC_MSG_RESULT([no]) > > Does running the host python produce the same warnings? I'm wondering > whether you're running something like Arch and the inputrc is incompatible > with the readline in the native sysroot. I was checking the same thing and it does check for an empty output, the problem here is that with 'set term xy' you don't get an empty output but the module is imported fine, wouldn't be better to check if the command was executed successfully?
Here is the output in both cases: with "set term xy" $ ./tmp/work/i586-poky-linux/gpgme/1.8.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3 -c 'import distutils' 2>&1 readline: /etc/inputrc: line 19: term: unknown variable name $ echo $? 0 $ python3 -c 'import distutils' 2>&1 $ echo $? 0 without "set term xy" $ ./tmp/work/i586-poky-linux/gpgme/1.8.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3 -c 'import distutils' 2>&1 $ echo $? 0 $ python3 -c 'import distutils' 2>&1 $ echo $? 0 As you can see the command success in all cases, also is noteworthy that opensuse built-in python doesn't complain about the line, perhaps readline version has something to do here?
Yes, it would be safer if it just checked the status code instead of relying on the output being empty. Mariano, can you prepare a patch (and send it upstream)?
Patch sent by Ross B. and merged into master commit c3186382ae0e4576e587ae5c0c0952c906bb8926 Author: Ross Burton <ross.burton@intel.com> Date: Tue Apr 4 15:40:01 2017 +0100 gpgme: fix configure if 'import distutils' causes output on stderr There are a number of reasons that importing a module could cause output on stderr that isn't a fatal error (compatibilty problems with inputrc, or encoding warnings) so backport a patch from autoconf-archive to only check the exit code instead of asserting that stderr is empty. [ YOCTO #11231 ] (From OE-Core rev: ebfd79ae6e5954253c3bb0886d476be480b24de8) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>