Bug 223663 - qt4: multilib issues
qt4: multilib issues
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qt4 (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-21 10:24 EST by Laurent Rineau
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-03 08:42:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for qt4-4.2.2-2. (3.00 KB, patch)
2007-02-17 12:38 EST, Laurent Rineau
no flags Details | Diff
multilib patch, take2 (1.50 KB, patch)
2007-02-27 11:33 EST, Rex Dieter
no flags Details | Diff
multilib qconfig.h (375 bytes, text/plain)
2007-02-27 11:33 EST, Rex Dieter
no flags Details
multilib qconfig.h, take 2 (415 bytes, text/plain)
2007-02-28 10:02 EST, Rex Dieter
no flags Details

  None (edit)
Description Laurent Rineau 2007-01-21 10:24:13 EST
I have tried to understand your choices of what is packaged in %{_libdir} and 
what is in %{_datadir}, and I am not sure to understand.

1) Why %{_libdir}/qt4/examples/ (in qt4-doc) while this directory only 
contains crossplatform source code?
2) In qt4-devel, %{_datadir}/qt4/mkspecs/ seems noarch, but I am pretty sure 
that the symlink %{_datadir}/qt4/mkspecs/default and and the config 
file %{_datadir}/qt4/mkspecs/qconfig.pri are platform-dependant.

I do not have a x86_64 machin to test, but I think that the two files in "2)" 
above may conflict if we install both i386 and x86_64 versions of qt4-devel.
Comment 1 Rex Dieter 2007-01-21 14:45:51 EST
>I have tried to understand your choices of what is packaged in %{_libdir} and 
>what is in %{_datadir}, and I am not sure to understand.

The original rationale was not multilib, but FHS compliance.  Took hints from
other distros, mostly.

>1) Why %{_libdir}/qt4/examples/ (in qt4-doc) while this directory only 
> contains crossplatform source code?

Look closer. (:  It also contains binaries built from said source code,
browseable via qtdemo

2) Is a valid multilib issue.  2 approaches:
a.  Move this back to %{_libdir}/qt4/mkspecs
b.  See if qt4 can support using *both* %_libdir/qt4/mkspecs and
%_datadir/qt4/mkspecs, and put the multilib-conflicting bits in
%_libdir/qt4/mkspecs (I was only previously aware of the 'default' symlink, but
you may also be right about qconfig).
Comment 2 Laurent Rineau 2007-01-22 03:16:56 EST
(If you agree, I would like to make this bug be a tracker for all multilib 
issues of qt4-devel, without creating separate bugs. I chance again the title. 
Please revert this change if you do not agree.)

%{_includedir}/QtCore/qconfig.h is another multilib issue.

This grep for "86" in %{_includedir}/Qt* seems to show that it is the only 
one: other i386 files are included according to proprocessor macros defined in 
<qconfig.h>.
Comment 3 Rex Dieter 2007-01-22 12:59:54 EST
Using this as a blocker is fine.

Here's the results of my quick-n-dirty multilib/conflicts test using my
el4.x86_64 box, the offenders/conflicts are:
/usr/include/Qt/qconfig.h 
/usr/include/QtCore/qconfig.h 
/usr/share/qt4/mkspecs/common/g++.conf 
/usr/share/qt4/mkspecs/default 
/usr/share/qt4/mkspecs/qconfig.pri 

qconfig.h is fixable, by doing something like:
rename Qt/qconfig.h Qt/qconfig-%{arch}.h
and create a new qconfig.h containing:
#include <Qt/qconfig-%{arch}.h>

For mkspecs conflicts, I'm still not sure.
Comment 4 Laurent Rineau 2007-01-23 08:03:25 EST
(In reply to comment #3)
> /usr/include/Qt/qconfig.h 
> /usr/include/QtCore/qconfig.h 

Same file.

> /usr/share/qt4/mkspecs/common/g++.conf 

It would be nice that Fedora's %{optflags} do not end in that file. We do not 
want to impose them to users.

> qconfig.h is fixable, by doing something like:
> rename Qt/qconfig.h Qt/qconfig-%{arch}.h
> and create a new qconfig.h containing:
> #include <Qt/qconfig-%{arch}.h>

Agree.

> For mkspecs conflicts, I'm still not sure.

I have begun to look in the code of qmake. It should be possible to make it 
look in several directories. The env variable QMAKEPATH can contain a list of 
directories.
Comment 5 Rex Dieter 2007-01-25 08:32:33 EST
> It would be nice that Fedora's %{optflags} do not end in that file. We do not 
> want to impose them to users.

I don't think I'd agree with you here.  qt4 apps should, by default, be built 
using the same flags used to build qt4.  If folks don't like/want that, they're 
free to modify it as they see fit (perhaps we could mark those mkspecs files %
config).

> The env variable QMAKEPATH can contain a list of directories.

I was hoping to come up with a solution that "just works" without resorting to 
env variables (but will resort to that if no better solution presents itself).
Comment 6 Laurent Rineau 2007-01-25 09:03:41 EST
(In reply to comment #5)
> > It would be nice that Fedora's %{optflags} do not end in that file. We do 
not 
> > want to impose them to users.
> 
> I don't think I'd agree with you here.  qt4 apps should, by default, be 
built 
> using the same flags used to build qt4.  If folks don't like/want that, 
they're 
> free to modify it as they see fit (perhaps we could mark those mkspecs 
files %
> config).

Actually, I think that there should be two platform fedora-32 and fedora-64 in 
$QTDIR/mkspecs/. See mkspecs/common/linux.conf, which is included by 
mkspecs/default/qmake.conf. That file defines several variables that are not 
accurate for Fedora:

QMAKE_INCDIR_X11      = /usr/X11R6/include
QMAKE_LIBDIR_X11      = /usr/X11R6/lib

QMAKE_INCDIR_OPENGL   = /usr/X11R6/include
QMAKE_LIBDIR_OPENGL   = /usr/X11R6/lib

What is more, we should have a kind of /etc/qt4/fedora-32.conf 
and /etc/qt4/fedora-64.conf in /etc, which defines the main flags.

> > The env variable QMAKEPATH can contain a list of directories.
> 
> I was hoping to come up with a solution that "just works" without resorting 
to 
> env variables (but will resort to that if no better solution presents 
itself).

I meant that, if qmake is enable to look in a list of directories, I should be 
possible to hard-code a default list of directories in its source code (with a 
patch).
Comment 7 Laurent Rineau 2007-02-17 12:38:23 EST
Created attachment 148274 [details]
Patch for qt4-4.2.2-2.

(In reply to comment #6)
> Actually, I think that there should be two platform fedora-32 and fedora-64
in 
> $QTDIR/mkspecs/. See mkspecs/common/linux.conf, which is included by 
> mkspecs/default/qmake.conf. That file defines several variables that are not 

> accurate for Fedora:
> 
> QMAKE_INCDIR_X11	= /usr/X11R6/include
> QMAKE_LIBDIR_X11	= /usr/X11R6/lib
> 
> QMAKE_INCDIR_OPENGL	= /usr/X11R6/include
> QMAKE_LIBDIR_OPENGL	= /usr/X11R6/lib

I have a patch, that create a platform mkspecs/linux-g++-fedora/, which should
be multilib. I have also remove all annoying LIBPATH and INCLUDEPATH (the flag
"-L/usr/lib" was making me crazy).

The prefix "linux-g++", in the name, is important: src/corelib/io/io.pri tests
for a platform name "linux-*".

This is a first step towards fix for multilib issue.
Comment 8 Rex Dieter 2007-02-17 13:26:33 EST
Thanks, I'll incorporate most of this into the next release.  I don't think I
agree with the need to create a separate "linux-g++-fedora" platform though.
Comment 9 Rex Dieter 2007-02-17 13:30:09 EST
On second thought, your implementation (after looking closer at the patch) looks
cleaner than any alternative I can think of right now... (:
Comment 10 Laurent Rineau 2007-02-17 13:46:28 EST
Thank you.

Actually, the implementation is wrong as is: %{optflags} is not the same on 
i386 and x86_64.

Maybe linux-g++-fedora/linux-g++-64/ should be excluded from i386 builds, and 
linux-g++-fedora/linux-g++-32/ be excluded from x86_64 builds. And 
common/g++.conf (or at least it variable QMAKE_CFLAGS_RELEASE) should be moved 
in linux-g++-{32,64}/ too, because QMAKE_CFLAGS_RELEASE is the variable that 
is "sedded" into %{optflags}.

The same sort of things as for linux-g++-fedora/qmake.conf can be used for 
mkspecs/qconfig.pri.

As for qconfig.h, that one is easy. I hope that we can deal with multilib 
issue very soon.

But, at least, please kill that linker flag -L/usr/lib/!!! :-) It comes from 
the variable QMAKE_LIBDIR_QT in common/linux.conf

You could publish intermediate tries for patches in that bug, so that I can 
work with you, if you want.
Comment 11 Laurent Rineau 2007-02-26 12:58:36 EST
(In reply to comment #10)
> But, at least, please kill that linker flag -L/usr/lib/!!! :-) It comes from 
> the variable QMAKE_LIBDIR_QT in common/linux.conf

What is the progress, on that topic? That "-L/usr/lib" really get me crazy!
Comment 12 Rex Dieter 2007-02-26 13:20:05 EST
working on it, slowly.  Turns out the header thing wasn't quite as trivial as I
previously thought, will need to iterate over all supported archs, using
something like:

/* qconfig.h */

#if defined(__i386__)
#include qconfig-i386.h
#elif defined(__x86_64__)
#include qconfig-x86_64.h
...
#endif

Comment 13 Rex Dieter 2007-02-26 13:43:55 EST
What harm does -L/usr/lib do exactly?  (It seems, to me, like a lot of extra
work to remove, for little gain)
Comment 14 Laurent Rineau 2007-02-26 14:03:50 EST
I am creating plugins for ipe (a drawing editor, see `rpm -qi ipe`). ipe uses 
Qt4, and ipe plugins usually use qmake.

If i add CONFIG+=qt in a .pro file, I get "-L/usr/lib" in linker flags.

My plugins use libCGAL.so (see `rpm -qi CGAL`).

In the development stage, I want them to use a patched version of libCGAL, 
that I have in $HOME/CGAL/lib/. Even if I add $CGAL/CGAL/lib to LIBPATH, in my 
pro files, -L$CGAL/CGAL/lib comes after -L/usr/lib/... and /usr/lib/libCGAL.so 
is found before my libCGAL.so in $HOME/CGAL/lib/. :-(
Comment 15 Rex Dieter 2007-02-26 14:27:09 EST
ah gotcha, not really a multilib issue though. (: I'll address that separately.
Comment 16 Rex Dieter 2007-02-27 11:31:40 EST
ok, I think we've got something workable, though I've found that the qconfig.h
modification breaks at least one app: PyQt4 (it's configure loads/groks
qconfig.h directly to parse QT_* defines).  I don't think there's any way around
that though.

Here's the specfile multilib additions (in a nutshell):
...
Source5: qconfig.h
...
%build
...
sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf

%install
...
## multilib: qconfig
mv %{buildroot}%{qt_headerdir}/Qt/qconfig.h
%{buildroot}%{qt_headerdir}/Qt/qconfig-%{_arch}.h
install -p -m644 -D %{SOURCE5} %{buildroot}%{qt_headerdir}/Qt/qconfig.h
mv %{buildroot}%{qt_headerdir}/QtCore/qconfig.h
%{buildroot}%{qt_headerdir}/QtCore/qconfig-%{_arch}.h
install -p -m644 -D %{SOURCE5} %{buildroot}%{qt_headerdir}/QtCore/qconfig.h
## mkspecs/default
rm -f %{buildroot}%{qt_datadir}/mkspecs/default
mkdir %{buildroot}%{qtdir}/mkspecs
ln -s %{qt_datadir}/mkspecs/%{platform} %{buildroot}%{qtdir}/mkspecs/default
# omit non-platform linux-g++*
pushd %{buildroot}%{qt_datadir}/mkspecs
for specdir in linux-g++* ; do
  if [ "$specdir" != "%{platform}"]; then rm -rf "$specdir"; fi
done
popd
Comment 17 Rex Dieter 2007-02-27 11:33:33 EST
Created attachment 148871 [details]
multilib patch, take2
Comment 18 Rex Dieter 2007-02-27 11:33:56 EST
Created attachment 148872 [details]
multilib qconfig.h
Comment 19 Laurent Rineau 2007-02-27 12:09:07 EST
(In reply to comment #17)
> Created an attachment (id=148871) [edit]
> multilib patch, take2

How will you handle %{_optflags}?
Comment 20 Rex Dieter 2007-02-27 12:16:34 EST
> How will you handle %{_optflags}?

sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf
Comment 21 Laurent Rineau 2007-02-27 13:15:42 EST
(In reply to comment #20)
> > How will you handle %{_optflags}?
> 
> sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf

Yes. I have eventually seen that you have made mkspecs being in %{_libdir}, 
which solves the multilib issue.
Comment 22 Rex Dieter 2007-02-27 14:12:46 EST
> you have made mkspecs being in %{_libdir}, 

Only %{qtdir}/mkspecs/default lives there (for now).  Everything else is (still)
in %{qt_datadir}.

OK, now let's see if this sucker actually builds... (:
Comment 23 Rex Dieter 2007-02-28 08:05:15 EST
The deed is done, in devel/fc7 only (for now), will queue FC-5/FC-6 builds soonish.

%changelog
* Tue Feb 27 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-3
- drop ./configure -no-reduce-exports (ie, support visibility)
- multilib issues (#223663)
Comment 24 Rex Dieter 2007-02-28 09:29:30 EST
Upon further testing, qconfig-multilib didn't work in all cases, REOPENING. 
Need to change references to
#include<qconfig-%_arch.h> -> #include<QtCore/qconfig-%_arch.h>.

In retrospect (mostly after finding how broken PyQt4 is), I'm considering reverting
-datadir %{qt_datadir}
or more precisely, change qt_datadir from _datadir/qt4 back to %_libdir/qt4

(CC'd Frank/qt4-qsa).

I'm on the fence wrt qt_datadir, in a nutshell, options are:
1.  Stick with %_datadir/qt4 , live with extra hackery to make multilib work,
deal-with/fix broken packages (like PyQt4)
2.  revert back to %_libdir/qt4, reduces/eliminates multilib hackery.

opinions?
Comment 25 Laurent Rineau 2007-02-28 09:41:38 EST
I would personally have preferred the hard way:
  - force Qt-4 being FSH compliant, with patches
  - force Qt-4 being multilib, with patches
  - give feedback to Trolltech to merge patches with upstream,
  - fix broken packages.

But I can understand that it is a lot of work. I have offered in the past to 
co-maintain some stuff with you, Rex, but :
  1/ I am not sure to be sufficiently involved in Fedora to have a right view 
of the The Right Thing In Fedora,
  2/ I have to finish my PhD thesis until end of June. => I will be even less 
involved in Fedora in the following months.

If you prefere not to delegate, or if nobody can co-maintain Qt-4 with you, I 
can understand that you prefere to go back to %{_libdir}/qt4/. That is not 
that bad.

That was my 2 cents.
Comment 26 Rex Dieter 2007-02-28 09:50:53 EST
> If you prefere not to delegate, or if nobody can co-maintain Qt-4 with you

You've demonstrated ample competence and earned my trust, and since I have a
general rule never turn down help, I'll go submit the request to add you as
co-maintainer. (:

And, you've convinced me to "do the right thing" wrt FHS, multilib.
Comment 27 Rex Dieter 2007-02-28 10:02:27 EST
Created attachment 148923 [details]
multilib qconfig.h, take 2

#include<qconfig-%_arch.h> -> #include<QtCore/qconfig-%_arch.h>
Comment 28 Rex Dieter 2007-02-28 10:03:21 EST
just noticed a typo in there, will fix that... (:
Comment 29 Laurent Rineau 2007-02-28 10:13:45 EST
(In reply to comment #26)
> You've demonstrated ample competence and earned my trust, and since I have a
> general rule never turn down help, I'll go submit the request to add you as
> co-maintainer. (:

Unfortunately, I will be of little help, in next 4 months.

(In reply to comment #24)
> In retrospect (mostly after finding how broken PyQt4 is), I'm considering 
reverting
> -datadir %{qt_datadir}
> or more precisely, change qt_datadir from _datadir/qt4 back to %_libdir/qt4

It is possible to make PyQt4's configure.py use predefined flags, given on 
command line or by env variables, with limited autodetection?


As for other packages that use Qt4, what build tool do they use? I personally 
maintain Ipe, which only uses qmake-qt4 and make. That's why I only need that 
the qmake-qt4 is usable. sip seems to be another (broken) tool. It should be 
fixed, or worked around if possible.
Comment 30 Rex Dieter 2007-02-28 10:19:41 EST
> Unfortunately, I will be of little help, in next 4 months.

Just let me know when you're free/available again, and if you're still
interested in comaint...

> It is possible to make PyQt4's configure.py use predefined flags

Yeah, it's broken, but fixable.  It basically re-implements qmake without
actually using qmake. ):
Comment 31 Laurent Rineau 2007-02-28 10:44:41 EST
You seem to have fixed the qconfig.h problem, or are about to fix it.

As for qt_datadir, I have one idea: what Qt considers as sharable data should 
remain sharable data. We know that mkspecs/default is a problem, as well as 
patched qmake.conf-and-friends.

My "linux-g++-fedora" platform was not that bad, I think. One important 
feature of if was that we do not modify the mkspecs provided by Trolltech.

I have a new implementation (not tested by lack of time), that allows to 
compile i386 qt applications on a x86_64, without any pain (if all dep libs 
are multilib):

1/ In the spec file, add:
=====================QUOTE============================
cat > mkspecs-modifications.sed <<ENDOFSCRIPT
# Use $RPM_OPT_FLAGS instead of -O2
s|-O2|$RPM_OPT_FLAGS|g
# undefine QMAKE_STRIP, so we get useful -debuginfo pkgs
s|^QMAKE_STRIP.*=.*|QMAKE_STRIP             =|
# Remove all occurence to /usr/X11R6
s|/usr/X11R6/.*||g
# Make QMAKE_INCDIR_QT and QMAKE_LIBDIR_QT be empty to avoid anoying 
# flags -I/usr/include and -L/usr/lib*
s|QMAKE_INCDIR_QT.*=.*|QMAKE_INCDIR_QT       =|
s|QMAKE_LIBDIR_QT.*=.*|QMAKE_LIBDIR_QT       =|
ENDOFSCRIPT

mkdir mkspecs/fedora
for d in linux-g++ linux-g++-32 linux-g++-64; do 
  cp -a mkspecs/$d mkspecs/common mkspecs/fedora/
done
sed -i -f mkspecs-modifications.sed mkspecs/fedora/*/*.conf
===============END=OF=QUOTE============================

2/ Remove QMAKE_CFLAGS_RELEASE from mkspecs/fedora/common/g++.conf, and add 
QMAKE_CFLAGS_RELEASE=%{optflags} to mkspecs/fedora/linux-g++-32/qmake.conf 
(or -64 if %{_lib}==lib64).

3/ Pass "-platform fedora/linux-g++-32" (or -64) to configure.

4/ Create a wrapper %{_libdir}/qt4/bin/qmake that sets the env variable 
QMAKESPEC=%{_datadir}/qt4/mkspecs/fedora/linux-g++-32 (or -64) before calling 
qmake (if QMAKESPEC is not already in the user environment).

5/ Remove mkspecs/default completely.

6/ Explain that in a README.Fedora file. It should be transparent for all 
non-broken packages or users that do not try to work with qmake internals, but 
it is even better if it is documented.

7/ Try to fix broken packages. :-(
Comment 32 Rex Dieter 2007-02-28 11:22:09 EST
Hmm... 4/5 looks interesting.  Once QMAKESPEC is set 'default' shouldn't be
needed.  

Though maybe we can set QMAKESPEC via (something like) /etc/profile/qt4.sh. 
Stuff other than qmake can/does use QMAKESPEC (sip and friends PyQt, PyQt4,
PyKDE), though maybe we could just manually set QMAKESPEC here, since it's a
relatively small subset of pkgs.

I'll keep pondering...  I think we're getting close to an ideal solution.
Comment 33 Rex Dieter 2007-02-28 12:19:34 EST
Well, release early/often, so here's an incremental improvement.

* Wed Feb 28 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-5
- fixup qconfig-multilib.h (#223663)
- qt4.(sh|csh): define QMAKESPEC (#223663)
Comment 34 Laurent Rineau 2007-02-28 12:34:23 EST
(In reply to comment #32)
> Hmm... 4/5 looks interesting.  Once QMAKESPEC is set 'default' shouldn't be
> needed.

Do you maintain a package that uses qmake? In order to test. If not, you could 
try to "bootstrap Qt": skip configure, and use a compiled qmake (coming from 
an installed qt4-devel package) to compile libs of Qt (and not the tools).

It may work (but bug #230224 seems a blocker).
Comment 35 Rex Dieter 2007-02-28 12:39:38 EST
> Do you maintain a package that uses qmake?

I tested a few various qt4 pkgs, including PyQt4 and texmaker.

> It may work (but bug #230224 seems a blocker).

why?  This and bug #230224 aren't related, afaict.
Comment 36 Laurent Rineau 2007-02-28 13:28:56 EST
(In reply to comment #35)
> > Do you maintain a package that uses qmake?
> 
> I tested a few various qt4 pkgs, including PyQt4 and texmaker.

PyQt4 does magic stuff to work around qmake. What about texmaker?

> > It may work (but bug #230224 seems a blocker).
> 
> why?  This and bug #230224 aren't related, afaict.

If you try to compile/bootstrap Qt libs with /usr/bin/qmake-qt4 (from Fedora), 
it can work correctly if qmake inserts -L/usr/lib and -I/usr/include at the 
beginning of flags.
Comment 37 Kevin Kofler 2007-03-03 19:43:58 EST
> As for other packages that use Qt4, what build tool do they use?

KDE 4 uses cmake, so at least that will have to work. :-)
Comment 38 Rex Dieter 2007-03-05 09:17:06 EST
qt4-4.2.2-5 builds fail on ppc:
/usr/include/QtCore/qconfig.h:15:3: error: #error arch unsupported, see http:

%changelog
* Mon Mar 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-7
- fixup qconfig-multilib.h for powerpc/powerpc64 (#223663)
Comment 39 Rex Dieter 2007-03-13 09:51:00 EDT
Ugh, more fun:

* Tue Mar 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-8
- multilib: qconfig.pri, /etc/profile.d/* (#223663)

This is starting to get rediculous, maybe qt_datadir needs to revert
%_datadir/qt4 -> %qtdir(%_libdir/qt4)
as the number of hacks to make %_datadir/qt4 work are mounting.
Comment 40 Laurent Rineau 2007-03-13 10:20:50 EDT
(In reply to comment #39)
> This is starting to get rediculous, maybe qt_datadir needs to revert
> %_datadir/qt4 -> %qtdir(%_libdir/qt4)
> as the number of hacks to make %_datadir/qt4 work are mounting.

We should work with upstream (Trolltech), so that Qt-4.3.0 helps this task. 
The datadir of Qt-4.x should be architecture independent.

Do you see a reasonable patch that could be merged upstream?
Comment 41 Rex Dieter 2007-03-13 10:29:34 EDT
> Do you see a reasonable patch that could be merged upstream?

atm, no, but I'll start a discussion on the qt4-interest ml soon.

Comment 42 Rex Dieter 2007-03-13 10:49:00 EDT
OK, this should do the trick

%changelog
* Tue Mar 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.3-1
- qt-4.2.3
- multilib: move arch-specific/conflicting mkspecs bit to %%qtdir/mkspecs (#223663)

arch-specific/conflicting mkspecs bits include:
default
qconfig.pri
linux-g++* (play it safe here)
Comment 43 Laurent Rineau 2007-04-03 05:45:43 EDT
Rex, what is the status of this bug? I have not managed to read all the story 
with details.
Comment 44 Kevin Kofler 2007-04-03 06:18:18 EDT
Uh, you accidentally changed the component, can you or someone in fedorabugs 
please change it back?
Comment 45 Laurent Rineau 2007-04-03 06:50:37 EDT
(In reply to comment #44)
> Uh, you accidentally changed the component, can you or someone in fedorabugs 
> please change it back?

Sorry. I hope my error will not change other fields (such as the owner).
Comment 46 Rex Dieter 2007-04-03 08:42:20 EDT
Should be fully resolved now, closing.

Note You need to log in before you can comment on or make changes to this bug.