Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1303289

Summary: mapnik 3.0.9-10 not built with $RPM_OPT_FLAGS
Product: [Fedora] Fedora Reporter: Ville Skyttä <ville.skytta>
Component: mapnikAssignee: Tom Hughes <tom>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: alex, cristian.balint, rdieter, tom
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-15 15:35:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 496968, 1279265    

Description Ville Skyttä 2016-01-30 09:24:30 UTC
mapnik 3.0.9-10 (nor -9) is no longer built with $RPM_OPT_FLAGS, see build logs and incomplete debuginfo. -8 did not have this problem.

Comment 1 Tom Hughes 2016-01-30 10:17:08 UTC
I see nothing in that would cause the build flags to change (other than dropping the rpath from the link) so this seems to be a mystery.

Maybe some change in another package has triggered it somehow?

Comment 2 Tom Hughes 2016-01-30 10:51:12 UTC
I don't see any change in the flags in the logs between -8 and -9 in fact as best I can see none of the 3.x builds have been using the right flags.

Comment 3 Ville Skyttä 2016-01-30 10:57:30 UTC
Seeing that mapnik uses qt, I was from the start quite convinced that this was the result of bug 1279265 comment 13. But in skimming the commits and specfile I somehow missed the direct qmake-qt4 invocation in the specfile. So that is most likely part of the problem.

However, I suppose there is more to it that might have been lurking there for a longer time, because the build does RPM_OPT_FLAGS tweaking with SConstruct, but apparently doing that doesn't affect the build in any way (the flags don't end up showing anywhere in the current build log). This should be investigated.

(In reply to Tom Hughes from comment #2)
> I don't see any change in the flags in the logs between -8 and -9 in fact as
> best I can see none of the 3.x builds have been using the right flags.

You seem to be right. Maybe the qmake thing has just been shadowing the issue until now.

Comment 4 Tom Hughes 2016-01-30 12:28:32 UTC
Unfortunately it seems the builders can't cope when the compiler options are used - the x86 build died with:

virtual memory exhausted: Operation not permitted
scons: *** [src/renderer_common/process_group_symbolizer.os] Error 1
scons: building terminated because of errors.

Comment 5 Rex Dieter 2016-01-30 15:25:13 UTC
fyi, you'll also want to replace the call to
in the .spec to use

Comment 6 Tom Hughes 2016-02-02 18:53:29 UTC
I've managed to build it with the right optimisation flags now, but I had to disable debug generation for the 32 bit platforms to avoid koji running out of memory.

Upstream has already done some work to refactor the problem code so the compiler has an easier time with it so I'm hopeful that the next release will allow me to remove the bodge.

Comment 7 Jan Kurik 2016-02-24 14:22:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:

Comment 8 Rex Dieter 2016-04-15 15:35:45 UTC
I'm assuming/hoping this is fixed since,

* Wed Mar  2 2016 Tom Hughes <tom> - 3.0.10-1
- Add upstream patch to reduce compile time memory usage
- Re-enable debugging on x86 to stop koji running out of memory

Feel free to re-open if that's not the case.

Comment 9 Tom Hughes 2016-04-15 15:44:00 UTC
Yes, it should be fixed now, even if that changelog entry is semi-nonsensical...