Your message dated Wed, 15 Apr 2009 09:00:47 +0200 with message-id <[email protected]> and subject line Re: Bug#523030: wrong quoting in aclocal's python.m4 check has caused the Debian Bug report #523031, regarding wrong quoting in aclocal's python.m4 check to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 523031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523031 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: automake1.10 Version: 1:1.10.1-3 Severity: serious ++ /usr/bin/python -c 'from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='\''${prefix}'\'')' this comes from: /usr/share/aclocal-1.10/python.m4: AC_SUBST([PYTHON_PREFIX], ['${prefix}']) AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}']) ... [am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')" 2>/dev/null || echo "$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages"`]) the expanded $prefix has to be passed to the python -c command. so as long as the fallback points to the correct location, all is ok. For python2.6 we will use dist-packages instead of site-packages, so the fallback is wrong. same in automake-1.9
--- End Message ---
--- Begin Message ---Ralf Wildenhues schrieb: > Hello Matthias, > > * Matthias Klose wrote on Tue, Apr 14, 2009 at 09:13:24AM CEST: >> '${prefix}' and '${exec_prefix}' are passed unexpanded to get_python_lib()), >> and >> the macro then defaults to the hardcoded alternative case. The patch passes >> the >> real path names to get_python_lib(), and only for the case, where the prefix >> argument was specified on the command line (the case for a missing prefix >> argument is handled inside the get_python_lib() function). >> >> tested the macro with python versions 2.0 up to trunk, and the 3.0 and 3.1 >> branches. > > Thanks for the bug report and patch. The way I read "info Automake > Python", the non-expanded '${prefix}' and '${exec_prefix}' were done > on purpose. Now, I'm not a python expert, nor have I worked much with > the Automake support code for python (except for accepting a patch into > the git tree that adds python 3.0 support). Can you describe or provide > an example that is fixed with your patch and broken without, and look > over the above-mentioned section in the manual, to see whether it still > describes the situation accurately with your patch? thanks for the pointer. I think the macro does work as designed, but I didn't expect the macro always passing the prefix= argument (and the macro maybe makes the assumption that the value passed is not checked/interpreted). So my bad on this assumption. Another (unrelated) issue with this macro is that it doesn't use the site directory of the python interpreter that it is configured for. Assume PYTHON=/opt/bin/python2.5 configure --prefix=/foo installs into /foo/lib/python2.5/site-packages, which is not on sys.path of the python2.5 in /opt/bin. closing the report, maybe address the unrelated issue upstream. Matthias
--- End Message ---
