This is a regression introduced in 4.8.5-19. Please apply quickly or tell me if you'd like me to do it to limit the damage done; due to this at least the following rawhide packages now have useless debuginfo and need a respin once this is in: libaccounts-qt, qbittorrent, qca2, qsstv, qt-mobility, qtwebkit, texmaker
Created attachment 871978 [details] Fix QMAKE_STRIP handling
I'm taking care of this. I'll just fix the sed expressions to do the right thing. (Your patch is not correct as is, the rm line deletes the wrong file (the original instead of the backup).)
I'm building a fixed qt now, I'll rebuild the affected packages ASAP. (I'm a provenpackager.)
I also fixed the sed in qt5-qtbase, where this was copied from: The sed was not wrong for the currently used Qt 5, but it hardcoded the amount of whitespace (which was why it didn't work on Qt 4).
This is my list of affected packages (built against Qt 4 using qmake after qt-4.8.5-19.fc21, verified to have empty -debuginfo): gqrx libaccounts-qt qbittorrent qca2 qsstv qt-mobility qtwebkit texmaker ugene (The packages qupzilla, subsurface and x2goclient also satisfy the other criteria, but have a valid -debuginfo. In qupzilla's case, it's probably because qupzilla.spec sets CONFIG+=debug, for the other 2 packages, I don't know, but there was clearly no stripping going on there.) Finding out which packages use qmake required a lot of manual checking, because it is often hidden behind some handwritten configure script or makefile. :-(
*** Bug 1069116 has been marked as a duplicate of this bug. ***
All the affected packages have been rebuilt now.
(In reply to Kevin Kofler from comment #2) > I'll just fix the sed expressions to do the right thing. Your call, but this bug is good evidence why patching is a superior approach -- things are a lot less likely to go unnoticed with them compared to sed'ing. BTW I suppose one cleaner but somewhat more laborous approach to this would have been to leave the QMAKE_STRIPs as is but undefine them in %qmake_qt4 and have all applicable packages use the macro.
I like the suggestion of tweaking this somehow in %qmake_qt4 macro, will have to look into implementing that.
The effect would be that non-RPM qmake builds would get stripped by default, is that really an improvement?
(In reply to Kevin Kofler from comment #10) > The effect would be that non-RPM qmake builds would get stripped by default, > is that really an improvement? It's what upstream has decided to do by default. That's not something we want in Fedora package builds, and we override it, but I don't think we should inflict that policy to completely unrelated end user builds. People not satisfied with upstream defaults can and should take it to upstream.