update python.m4 to the version integrated upstream

This bug was fixed in the package automake1.10 - 1:1.10.2-1ubuntu2

---------------
automake1.10 (1:1.10.2-1ubuntu2) karmic; urgency=low

  * python.m4: Update to the patch integrated upstream. LP: #377584.
    m4/python.m4 (AM_PATH_PYTHON): When computing pythondir and
    pyexecdir, pass the expanded prefix resp. exec_prefix as `prefix'
    to get_python_lib, so python can determine the name of the site
    directory depending on the install location. Afterwards, replace
    the directory names with the unexpanded values of $PYTHON_PREFIX
    resp. $PYTHON_EXEC_PREFIX again, to allow override according to
    the documentation. Fixes site directory computation for Debian
    and Ubuntu (`dist-packages' for a prefix of `/usr' or `/usr/local',
    `site-packages' elsewhere).

 -- Matthias Klose <email address hidden> Sun, 17 May 2009 14:47:41 +0200

This bug was fixed in the package automake1.9 - 1.9.6+nogfdl-3ubuntu3

---------------
automake1.9 (1.9.6+nogfdl-3ubuntu3) karmic; urgency=low

  * python.m4: Update to the patch integrated upstream. LP: #377584.
    m4/python.m4 (AM_PATH_PYTHON): When computing pythondir and
    pyexecdir, pass the expanded prefix resp. exec_prefix as `prefix'
    to get_python_lib, so python can determine the name of the site
    directory depending on the install location. Afterwards, replace
    the directory names with the unexpanded values of $PYTHON_PREFIX
    resp. $PYTHON_EXEC_PREFIX again, to allow override according to
    the documentation. Fixes site directory computation for Debian
    and Ubuntu (`dist-packages' for a prefix of `/usr' or `/usr/local',
    `site-packages' elsewhere).

 -- Matthias Klose <email address hidden> Sun, 17 May 2009 14:59:46 +0200

What is the rationale for updating this in jaunty, and what's the scope/patch? This sounds like something which can potentially break the build or change the behaviour of existing packages in jaunty, should they need to be rebuilt on Jaunty due to a SRU or security update.

> This sounds like something which can potentially break the build or change the behaviour of existing packages in jaunty

no, it doesn't.

it's a no change for building packages in Ubuntu, but brings the python packages back in sync with the upstream behaviour not expanding ${prefix} and ${exec_prefix}

Can you please add the SRU description, why the change is necessary, what the scope is, and why it is reasonably safe for regressions?

<doko> pitti: would you mind explaining for #377584 what you are missing?
<pitti> doko: see comment 5
<doko> pitti: what don't you understand in comment 4?
<pitti> doko: well, "not expanding ${prefix}" doesn't really describe a bug or a fix, or why it is critical to update this in stables
<doko> pitti: because it restores autoconf's upstream behaviour
<pitti> doko: so it was broken in jaunty?
<pitti> doko: an SRU has to demonstrate what's broken, and how to test it
<doko> it doesn't matter for jaunty, but it does matter for autoconf generated scripts which are used outside of Ubuntu
<pitti> right now there is no way to tell the severity, how to verify an update, and what potential breakage it has for jaunty
<doko> pitti: run a configure script generated by autoconf with and without the patch. I assume that should be enough to demonstrate the behaviour
<pitti> right, and exactly this kind of information is missing
<pitti> - example configure script (or package, or URL to upstream project, etc.)
<pitti> - if I use teh jaunty automake, what breaks?
<pitti> - the update fixes that breakage, how should its output/behaviour look like?
<pitti> - how did it behave in hardy/intrepid? when did it regress?
<pitti> doko: ^
<doko> pitti: sorry that's pedantic. I'll paste this to the bug report.
<pitti> doko: pedantic? right now there is nothing in that bug report that tells _anyone_ why this SRU is necessary
<pitti> and I'm not going to accept a basic toolchain change into a stable release without at least some justification and test cases
<pitti> (and yes, SRUs need to be pendantic by definition)
<doko> pitti: there is: it's a no change for building packages in Ubuntu, but brings the python packages back in sync with the upstream behaviour not expanding ${prefix} and ${exec_prefix}
<doko> and it does exactly decribe the change
<pitti> right, the techical implementation ("not expand blabla"), but not the actually visible behavioural change/impact/justification
<pitti> and unless someone can actually test it, this won't ever go to -updates

how to reproduce:

 - run a configure script with the AM_PATH_PYTHON macro expanded
 - check the output that PYTHON_PREFIX and PYTHON_EXEC_PREFIX
   start with the unexpanded ${prefix} and ${exec_prefix} macros.

So, since there is still no clear test case here, I tried to download pygtk sources. Upstream configure is not built on Ubuntu. I ran autoreconf, and diff'ed the original and newly produced configure. The definition of PYTHON_PREFIX and PYTHON_EXEC_PREFIX didn't change. So what's the actual error here, which problem does this try to solve? Or is pygtk a bad test case? If it only happens with some projects, please tell which project it can be tested with.

simple configure.ac, but any configure.ac using AM_PATH_PYTHON() is enough
AC_INIT()
AM_PATH_PYTHON()
AC_CONFIG_FILES(foo.in)
AC_OUTPUT

output in jaunty:
$ ./configure
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... /usr/lib/python2.6/dist-packages
checking for python extension module directory... /usr/lib/python2.6/dist-packages
configure: creating ./config.status

correct behaviour is not to expand the variables and keeping the ${prefix} and ${exec_prefix} macros

Hm, isn't configure meant to set --prefix and expand it? What does the current behaviour break?

Accepted automake1.9 into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted automake1.10 into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Martin Pitt schrieb:
> Hm, isn't configure meant to set --prefix and expand it?

yes, prefix, but not other macros defined in terms of prefix.

> What does the current behaviour break?

make prefix=/something. The fixed behaviour gets it right for PYTHON_PREFIX as well.

checked both automake1.9 and 1.10 for the correct behaviour described in comment 8

Will the packages in -proposed be approved/pushed to -updates anytime soon?

This bug was fixed in the package automake1.10 - 1:1.10.2-0ubuntu3.09.04

---------------
automake1.10 (1:1.10.2-0ubuntu3.09.04) jaunty-proposed; urgency=low

  * python.m4: Update to the patch integrated upstream. LP: #377584.
    m4/python.m4 (AM_PATH_PYTHON): When computing pythondir and
    pyexecdir, pass the expanded prefix resp. exec_prefix as `prefix'
    to get_python_lib, so python can determine the name of the site
    directory depending on the install location. Afterwards, replace
    the directory names with the unexpanded values of $PYTHON_PREFIX
    resp. $PYTHON_EXEC_PREFIX again, to allow override according to
    the documentation. Fixes site directory computation for Debian
    and Ubuntu (`dist-packages' for a prefix of `/usr' or `/usr/local',
    `site-packages' elsewhere).

 -- Matthias Klose <email address hidden> Sun, 17 May 2009 15:07:12 +0200

This bug was fixed in the package automake1.9 - 1.9.6+nogfdl-3ubuntu2.09.04

---------------
automake1.9 (1.9.6+nogfdl-3ubuntu2.09.04) jaunty-proposed; urgency=low

  * python.m4: Update to the patch integrated upstream. LP: #377584.
    m4/python.m4 (AM_PATH_PYTHON): When computing pythondir and
    pyexecdir, pass the expanded prefix resp. exec_prefix as `prefix'
    to get_python_lib, so python can determine the name of the site
    directory depending on the install location. Afterwards, replace
    the directory names with the unexpanded values of $PYTHON_PREFIX
    resp. $PYTHON_EXEC_PREFIX again, to allow override according to
    the documentation. Fixes site directory computation for Debian
    and Ubuntu (`dist-packages' for a prefix of `/usr' or `/usr/local',
    `site-packages' elsewhere).

 -- Matthias Klose <email address hidden> Sun, 17 May 2009 14:59:46 +0200