Bug 1074041

Summary: Fix QMAKE_STRIP handling
Product: [Fedora] Fedora Reporter: Ville Skyttä <ville.skytta>
Component: qtAssignee: Kevin Kofler <kevin>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dvratil, itamar, jreznik, kevin, ltinkl, rdieter, rnovacek, smparrish, than
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: qt-4.8.5-23.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-08 01:21:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 496968    
Attachments:
Description Flags
Fix QMAKE_STRIP handling none

Description Ville Skyttä 2014-03-07 18:04:20 UTC
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

Comment 1 Ville Skyttä 2014-03-07 18:04:25 UTC
Created attachment 871978 [details]
Fix QMAKE_STRIP handling

Comment 2 Kevin Kofler 2014-03-08 01:09:57 UTC
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).)

Comment 3 Kevin Kofler 2014-03-08 01:21:03 UTC
I'm building a fixed qt now, I'll rebuild the affected packages ASAP. (I'm a provenpackager.)

Comment 4 Kevin Kofler 2014-03-08 01:28:42 UTC
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).

Comment 5 Kevin Kofler 2014-03-08 03:34:00 UTC
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. :-(

Comment 6 Kevin Kofler 2014-03-08 22:21:22 UTC
*** Bug 1069116 has been marked as a duplicate of this bug. ***

Comment 7 Kevin Kofler 2014-03-09 00:10:19 UTC
All the affected packages have been rebuilt now.

Comment 8 Ville Skyttä 2014-03-09 08:54:49 UTC
(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.

Comment 9 Rex Dieter 2014-03-22 13:56:00 UTC
I like the suggestion of tweaking this somehow in %qmake_qt4 macro, will have to look into implementing that.

Comment 10 Kevin Kofler 2014-03-23 00:51:25 UTC
The effect would be that non-RPM qmake builds would get stripped by default, is that really an improvement?

Comment 11 Ville Skyttä 2014-03-23 08:18:07 UTC
(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.