Bug 13942

Summary:	Bug in spec file from qt4-4.8.4-7.mga3.src.rpm
Product:	Mageia	Reporter:	Gilles Allard <gilles.allard21>
Component:	RPM Packages	Assignee:	Luc Menut <lmenut>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	balcaen.john, mageia
Version:	Cauldron
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	qr4-4.8.4-7.mga3.src.rpm	CVE:
Status comment:

Description Gilles Allard 2014-08-19 18:03:42 CEST

Description of problem:
1) If the package "libmeasopenvg" is installed, configure detects it (the default value assigned to "-openvg" arg is "auto") and all components of the QtOpenVG sub-package are built and installed. But no "QtOpenVG" sub-package is described in the spec file.
The result is a failure of the install step because installed files are found unpackaged.
This failure is due to a missing "-no-openvg" argument for "configure".
Adding this arg solves the problem.

2) This is not a bug but a proposal for an improvement to the build process of Qt4.
Because of the "-webkit" argument of configure, all the components of "QtWebKit" sub-package are built & installed; at the end of the install step, they are deleted because this sub-package is not provided by Qt4 package.
This build takes a long time just for nothing.
The proposed cleanup of the spec file is :
- change configure arg from "-webkit" to "-no-webkit" to prevent building of this module and spare some time
- remove the sequence used to delete all the just built files (apart from the "tst_*" part)

Version-Release number of selected component (if applicable):
qt4-4.8.4-7.mga3.src.rpm

How reproducible:
Easily reproducible if "libmesaopenvg" package is installed on the build machine

Steps to Reproduce:
1.Install "libmesaopenvg" package
2.Start a build of Qt4
3.The build fails due to installed but not packaged files


Reproducible: 

Steps to Reproduce:

Comment 1 David Walser 2014-08-19 19:57:35 CEST

Thanks for the report.  I don't see a need to issue an update just for this, but cutting down on the build time would be nice, so if we fix this we could check the fix into SVN for Mageia 3 and Mageia 4.

CC: (none) => balcaen.john, mageia
Version: 3 => Cauldron
Assignee: bugsquad => lmenut

Comment 2 Luc Menut 2014-08-19 22:19:50 CEST

We build QtWebKit on purpose. If we didn't build QtWebKit, we disabled QtWebKit support for QtHelp and Qt Assistant. I don't checked recently, but it's probably still true. I just checked, Fedora still does like us.

-------- Message original --------
Sujet: Re: Request for QtWebKit-2.2 tests and feedback
Date : Tue, 09 Aug 2011 18:04:08 +0200
De : Thiago Macieira <thiago@kde.org>
Répondre Ã  : kde-devel@kde.org
Pour : kde-devel@kde.org

On Tuesday, 9 de August de 2011 11:41:17 Ademar Reis wrote:
> One of the best (simplest) ways to test it is by building Qt with
> configure -no-webkit and then building QtWebKit-2.2 in standalone mode
> from our git branch (updated a couple of times a week, weekly beta
> releases are also made from there). Qt-4.8 includes a snapshot from
> the QtWebKit-2.2 branch, but it's not always up-to-date.

I recommend against that. If you do it, you'll disable QtWebKit support for 
QtHelp and Qt Assistant. Last I checked, that codepath doesn't build due to 
not being tested.

So build both webkits if you have Qt 4.7, or just use Qt 4.8.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

For 1), we never add all possibles options in configure, especially on such big package.

Comment 3 Luc Menut 2015-02-23 20:55:59 CET

I added '-no-openvg' in last builds of qt4 in Cauldron and Mageia 4.

Status: NEW => RESOLVED
Resolution: (none) => FIXED