allow setting more build flags from the environment

fixed in the intrepid package

Can you please add a test case to verify that it works?

Accepted into -proposed, please test and give feedback here

Also, what's the rationale why we need to change that in stables?

I have used the new version for some weeks without any problem.

testcase: pick any package building an extension, e.g. python-imaging. Without this patch the default options -fno-strict-aliasing and -fwrapv are not seen for python2.5 builds, with this patch these are included on the command line, and additionally specifying CFLAGS to another value (.e.g -O3) works as expected (it's appended after the default CFLAGS). checked on i386 hardy, and hardy-proposed.

This does not sound to me like an appropriate change for an SRU; the chance of a regression affecting other SRU builds is very high, since this is a change that globally affects the build options seen by any python extensions when building. If there are specific extension packages that are broken without these default build options, I would be more comfortable with identifying those individually and kludging the build options on a per-package basis; those packages would need to be re-uploaded to take advantage of this change anyway.

Is there a decision here on whether to accept this SRU? If it is to be accepted, can the testcase be fleshed out and moved the description?

Thanks.

To me the rationale for SRUing this (comment 7) does not convince me, pretty much for the same reasons that Steve mentioned. Matthias, why is it so important to get this into hardy? Which Python packages are actually broken due to this ATM?

as explained on #ubuntu-devel ... this pessimizes the optimization flags (matching the optimization options for upstream and python2.4).

> Which Python packages are actually broken due to this ATM?

rebuilding the packages build depending on python2.5 with the fixed python2.5 package and testing against open bug reports should answer your question. Before anybody finds the time to do so we should make sure that packages which are rebuilt are using the -fno-strict-aliasig flag.

As discussed, there has been no analysis of the regression potential, or even of the exact packages that are supposed to benefit from this. In order to keep Ubuntu 8.04.1 on track, which will not include this package, I'm therefore removing it from hardy-proposed. Sorry, I don't think this package should ever have been accepted into -proposed with the available rationale. If a clearer case can be made for why this update is necessary, it can be reuploaded and tested after the point release.

This looks pretty stale now. Please reopen if there are any updates about this.