Bug 188180
|
Description
Rex Dieter
2006-04-06 18:07:30 UTC
Only lightly tested, but wanted to get this out there for more feedback/review. Im not going to have time for a full review on this but am going to watch
with interest.
I think the man pages should be installed inside the qt4 tree just for
additional documentation perhaps in %{qtdir}/man
Good point, I'll make sure to include %{qtdir}/man in the next pkg iteration.
%changelog * Thu Apr 06 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-3 - include manpages at %%qtdir/man Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-3.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.unstable/qt4-4.1.2-3.src.rpm Nevermind the update to qt4-4.1.2-3. Turns out the build fails, and the manpages that the .spec referred to before do not exist. %changelog * Mon Apr 10 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-4 - qt4.(sh|csh): place-holders only, don't define QTDIR (and QTLIB) as that (potentially) conflicts with qt-3.x. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-4.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.testing/qt4-4.1.2-4.src.rpm There's a typo in the summary of qt-config. Also, how about using -no-exceptions and sedding -fexceptions out of $RPM_OPT_FLAGS? Qt (and KDE 4 eventually) would be smaller and faster. Created attachment 127786 [details]
Disable C++ exceptions
This patch disables C++ exceptions. Here's the sizes of the libraries before
and after for comparison. This doesn't tell anything about runtime size and
speed but some Googling should make the difference clear.
With exceptions:
-rwxr-xr-x 1 root root 3.0M Apr 15 11:04 libQt3Support.so.4.1.2
-rwxr-xr-x 1 root root 1.4M Apr 15 11:04 libQtCore.so.4.1.2
-rwxr-xr-x 1 root root 1.1M Apr 15 11:04 libQtDesignerComponents.so.4.1.2
-rwxr-xr-x 1 root root 1.5M Apr 15 11:04 libQtDesigner.so.4.1.2
-rwxr-xr-x 1 root root 5.1M Apr 15 11:04 libQtGui.so.4.1.2
-rwxr-xr-x 1 root root 345K Apr 15 11:04 libQtNetwork.so.4.1.2
-rwxr-xr-x 1 root root 177K Apr 15 11:04 libQtOpenGL.so.4.1.2
-rwxr-xr-x 1 root root 209K Apr 15 11:04 libQtSql.so.4.1.2
-rwxr-xr-x 1 root root 254K Apr 15 11:04 libQtSvg.so.4.1.2
-rwxr-xr-x 1 root root 59K Apr 15 11:04 libQtTest.so.4.1.2
-rwxr-xr-x 1 root root 276K Apr 15 11:04 libQtXml.so.4.1.2
Without exceptions:
-rwxr-xr-x 1 root root 2.6M Apr 15 13:56 libQt3Support.so.4.1.2
-rwxr-xr-x 1 root root 1.2M Apr 15 13:56 libQtCore.so.4.1.2
-rwxr-xr-x 1 root root 968K Apr 15 13:56 libQtDesignerComponents.so.4.1.2
-rwxr-xr-x 1 root root 1.3M Apr 15 13:56 libQtDesigner.so.4.1.2
-rwxr-xr-x 1 root root 4.6M Apr 15 13:56 libQtGui.so.4.1.2
-rwxr-xr-x 1 root root 283K Apr 15 13:56 libQtNetwork.so.4.1.2
-rwxr-xr-x 1 root root 165K Apr 15 13:56 libQtOpenGL.so.4.1.2
-rwxr-xr-x 1 root root 177K Apr 15 13:56 libQtSql.so.4.1.2
-rwxr-xr-x 1 root root 206K Apr 15 13:56 libQtSvg.so.4.1.2
-rwxr-xr-x 1 root root 56K Apr 15 13:56 libQtTest.so.4.1.2
-rwxr-xr-x 1 root root 236K Apr 15 13:56 libQtXml.so.4.1.2
OK, sounds reasonable. %changelog * Sat Apr 15 2006 Simon Perreault <nomis80> - 4.1.2-5 - Disable C++ exceptions. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-5.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.testing/qt4-4.1.2-5.src.rpm Is compiling a C++ lib that should be usable for application developent without exceptions really a good idea? (I'd say no) Saving some ~3MB sounds like a bad argument for doing this, as for speed... I'd like to see measurements. It is possible to use exceptions with a Qt library compiled with -no-exceptions. KHTML uses exceptions and KDE's general policy is to assume Qt is compiled with exceptions disabled. Some googling revealed that the only theoretical problem would be when emitting exceptions from slots, or event handlers, or any function called by Qt's event loop, and not catching it and letting it propagate through Qt's stack, and then handling it in the main function. I did a small test, throwing an exception in such a place, and it propagates all the way up through Qt's stack without any problem. I can't see any problem with disabling exceptions in Qt. Any expert advice? I'll get around to posting the source code shortly. Oh, and by the way you need to know that Qt itself doesn't use exceptions, so disabling exceptions doesn't disable any error handling in Qt itself. Re: exceptions. It's completely safe either way, according to comment in
./configure:
------------------------------
Recent versions of this compiler automatically include code for
exceptions, which increase both the size of the Qt library and the
amount of memory taken by your applications.
You may choose to re-run `basename $0` with the -no-exceptions
option to compile Qt without exceptions. This is completely binary
compatible, and existing applications should continue to work.
------------------------------
%changelog * Thu Apr 27 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-6 - devel: Requires: pkgconfig Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-6.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-6.src.rpm I am not yet in group 'fedorabugs', but I can start a review. It is my first
review, so I hope it is what is expected.
Here is my review:
** MUST item, fix rpmlint warnings and errors:
W: qt4 strange-permission qt4.sh 0755
W: qt4 strange-permission qt4.csh 0755
Could be ignored: 0755 is the permission used for all other files
in /etc/profile.d
W: qt4 hardcoded-prefix-tag %{qtdir}
Do not use Prefix tag unless you motivate this choice. IMHO, qt4 cannot be
relocated easily. You should remove this tag.
E: qt4 configure-without-libdir-spec
You can ignore this one: Qt configure is not GNU/configure
W: qt4 non-conffile-in-etc /etc/ld.so.conf.d/qt4-x86_64.conf
Whereas the qt package in FC do not mark /etc/ld.conf.d/qt-*.conf as config
file, I think that files in /etc/ld.conf.d/ should be tagged as
%config(noreplace). If a user wants to modify those files, we should assume
that he knows what he does.
W: qt4 one-line-command-in-%post /sbin/ldconfig
W: qt4 one-line-command-in-%postun /sbin/ldconfig
May be ignored. No easy to fix. Maybe you could use:
%if "%{?ld_so_conf_d}" != "1"
%post
echo "%{qtdir}/lib" >> /etc/ld.so.conf
/sbin/ldconfig
%postun
if [ $1 -eq 0 ]; then
grep -v "^%{qtdir}/lib" /etc/ld.so.conf > /etc/ld.so.conf.new 2>/dev/null
mv -f /etc/ld.so.conf.new /etc/ld.so.conf
fi
/sbin/ldconfig
%else
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%endif
but I am not sure that it is a better choice.
E: qt4-designer devel-dependency qt4-devel
You can ignore this one.
W: qt4-devel summary-ended-with-dot Development files and documentation for
the Qt GUI toolkit.
Easy to fix.
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtNetwork.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtSvg.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtTest.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/Qt3Support.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtSql.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtGui.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtXml.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtCore.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtOpenGL.pc
It seems that qmake adds -L%{_buildir}/qt-x11-opensource-src-4.1.2/lib in
pkg-config files. It should should be sed off.
E: qt4-devel
arch-dependent-file-in-usr-share /usr/share/doc/qt4-devel-4.1.2/affine/affine
(repeted 123 times)
Please remove compiled demos and examples from the package.
W: qt4-devel conffile-without-noreplace-flag /etc/profile.d/qt4.csh
W: qt4-devel conffile-without-noreplace-flag /etc/profile.d/qt4.sh
Please use %config(noreplace) instead of %config alone. See par 'Configuration
Files' in http://fedoraproject.org/wiki/Packaging/Guidelines
E: qt4-devel executable-marked-as-config-file /etc/profile.d/qt4.csh
E: qt4-devel script-without-shellbang /etc/profile.d/qt4.csh
E: qt4-devel executable-marked-as-config-file /etc/profile.d/qt4.sh
E: qt4-devel script-without-shellbang /etc/profile.d/qt4.sh
Could be ignored, IMHO.
E: qt4-devel
script-without-shellbang /usr/lib64/qt4/mkspecs/macx-xcode/Info.plist.app
E: qt4-devel
script-without-shellbang /usr/lib64/qt4/mkspecs/macx-pbuilder/Info.plist.app
E: qt4-devel
script-without-shellbang /usr/lib64/qt4/mkspecs/macx-xcode/qmake.conf
E: qt4-devel
script-without-shellbang /usr/lib64/qt4/mkspecs/macx-pbuilder/qmake.conf
Nobody cares, IMHO.
W: qt4-devel
wrong-file-end-of-line-encoding /usr/share/doc/qt4-devel-4.1.2/tools/codecs/encodedfiles/iso-8859-15.txt
W: qt4-devel
wrong-file-end-of-line-encoding /usr/share/doc/qt4-devel-4.1.2/tools/codecs/encodedfiles/iso-8859-1.txt
Please ignore that warning: it seems to be intended.
W: qt4-devel
doc-file-dependency /usr/share/doc/qt4-devel-4.1.2/painting/svgviewer/svgviewer
libQtSvg.so.4()(64bit)
(repeted several times, for different compiled examples/demos)
Same as above.
W: qt4-MySQL summary-ended-with-dot MySQL drivers for Qt's SQL classes.
W: qt4-ODBC summary-ended-with-dot ODBC drivers for Qt's SQL classes.
W: qt4-PostgreSQL summary-ended-with-dot PostgreSQL drivers for Qt's SQL
classes.
W: qt4-SQLite summary-ended-with-dot SQLite drivers for Qt's SQL classes.
Should be fixed.
W: qt4-MySQL no-documentation
W: qt4-config no-documentation
W: qt4-designer no-documentation
W: qt4-ODBC no-documentation
W: qt4-PostgreSQL no-documentation
W: qt4-SQLite no-documentation
I do not see what documentation could be included, here.
(End of rpmlint stuff.)
** OK: naming follows the Package Naming Guidelines.
Actually, the section "Multiple packages with the same base name" of
http://fedoraproject.org/wiki/Packaging/NamingGuidelines does not cover the
case of a package named "qt4" that is more recent than the package named "qt",
but it seems the right choice.
** MUST: the package seems to conform to the Packaging Guidelines, except for
the items pointed out by rpmlint above, and the following item:
- I found two static libraries but they seem to be exception required by the
upstream build system: tools/assistant/lib/lib.pro and
tools/designer/src/uitools/uitools.pro both contain "CONFIG += staticlib". It
seems ok.
- The desktop file refers to the mime type x-designer. Actually, the file
%{_datadir}/mimelnk/application/x-designer.desktop is owned by kdelibs. Maybe
this is acceptable, but I must admit that I do not know. FC qt package suffers
from the same issue.
- The desktop file must be installed by desktop-file-install. See
http://fedoraproject.org/wiki/Packaging/Guidelines#desktop
- Should not %{qtdir}/etc be owned by the package qt4? Actually, I do not
understand the redhat_artwork stuff. Can you explain?
- The /etc/ld.so.conf.d stuff is not really clear. /etc/ld.so.conf.d is
requires by FC qt on FC-4 and FC-5. And I doubt that qt4 could be accepted for
previous versions of FC. Perhaps you should simplify your spec file by
assuming that /etc/ld.so.conf.d/ is required.
- Your spec file use both %{buildroot} and $RPM_BUILD_ROOT. According to
http://fedoraproject.org/wiki/Packaging/Guidelines#UsingBuildRootOptFlags you
should avoid to mixe the two forms.
- What is the %{name} == "qt" test for?
- Why these two lines?
# remove broken links
rm -f %{buildroot}%{qtdir}/mkspecs/default/linux-g++*
** OK: license is GPL/QPL, matches the upstream license, and the text of the
license(s) is in %doc.
** OK: the tarball md5sum matches the one in
ftp://ftp.trolltech.com/qt/source/md5sums.txt
** OK: the sources builds at least on x86_64, under FC-5.
** MUST: BuildRequires:
- BuildRequires: perl|sed|tar are optional, according to
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
- missing build requirements: libXcursor-devel and libXi-devel
** MUST: remove duplicate files in %files: if %{_lib}=="lib", I think that
%{qtdir}/lib is declared twice in the %files section:
%dir %{qtdir}/lib/
%{qtdir}/%{_lib}
** MUST: doc subpackage
I think that the documentation should go in a -devel-docs subpackage.
Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-8.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-8.src.rpm %changelog * Fri May 12 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-8 - simplify build* macros - lower-case all subpkgs (ie, -MySQL -> -mysql ) - drop BR: perl, sed * Thu May 11 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-7 - rework %%post/%%postun, mostly to placate rpmlint - drop Prefix: - drop use of qt4.(sh|csh), they're empty atm anyway - use Source'd designer.desktop (instead of inline cat/echo) - symlinks to %%_bindir: qmake4, designer4, qtconfig4 - drop qtrc, qt4 doesn't use it. - -docs subpkg for API html docs, demos, examples. - BR: libXcursor-devel libXi-devel (fc5+) sed: can't read config.tests/unix/checkavail: No such file or directory I'll remove this sed line and continue the build... Another odd thing: I cannot compile this spec (and the previous ones actually) without using option --define 'fedora 5' for rpmbuild. Where should this macro come from? Re: sed Oops. (Wonder how my builds completed then?) Re: fedora macro The Extras buildsystem defines the fedora macro. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-9.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-9.src.rpm %changelog * Fri May 12 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-9 - drop reference to non-existent config.test/unix/checkavail I have not yet looked at the generated RPMs, but I found some odd things: -Â Your spec file defines a sub-package named "styles", but there is no %files section for it. -Â Between 4.1.2-6 and 4.1.2-8, the diff shows that you remove LICENSE.QPL from packages. The license of qt4 free edition is GPL/QPL (even if Trolltech tries to make users forget the QPL license). Re: styles. I, at one time, included the option to make a -styles subpkg. I should probably remove that old crud. Re: Licensing and LICENSE.QPL From my reading of http://www.trolltech.com/company/about/businessmodel qt4 can be either used as GPL/opensource or commericial/QPL. However, on second though, it appears this applies to applications that use qt4, not qt4 itself, which is still dual licensed. I'll re-ad the QPL bits. What does mean "InitialPreference=5" in the desktop file? Hello, I have read your spec file. I think you can remove the motif stuff, because it is not longer an part of Qt. And the second you can add the option -no-qt3support to the config script. Because the Qt3 support of Qt4 is not very good. So at this time it is better to use Qt3 and not the Qt3 support layer of Qt4. I'd rather not -no-qt3support, since that currently breaks PyQt4. (In reply to comment #24) > And the second you can add the option > -no-qt3support to the config script. Because the Qt3 support of Qt4 is not very > good. So at this time it is better to use Qt3 and not the Qt3 support layer of Qt4. Please don't. A developper can use qt3to4 as a first step to migrate a Qt-3 application to Qt-4. And qt3to4 uses libQt3Support. Re: comment #23, InitialPreference: The .desktop file with the highest InitialPreference for a given mime type will be the default application. I guess it's mostly bogus, so I'll remove it. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-10.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-10.src.rpm %changelog * Sat May 13 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-10 - cleanup/simplify license bits, include LICENSE.QPL - drop unused -styles/-Xt subpkg reference - drop unused motif extention bits - drop initialpreference from .deskstop files Yes your are right for the migrate process the support layer be usefull. Only for release apps it is not. Will be better to name the variable
%define qt_dirname qt4
to %define qt_dirname qt-%{version} like it is in the Qt3 package?
Then it is mutch cleaner when the new KDE version comes witch build on Qt4.
I find /usr/lib/qt-4.2.1 better then only /usr/lib/qt4
Having installed the new packages, and done ugly things like
for f in $(rpm -qlp RPMS/x86_64/qt4-docs-4.1.2-9.x86_64.rpm); do \
ll $f -d --color=yes; \
done | less -r
here is my updated review:
** In:
for i in designer qmake qtconfig ; do
ln -s ../%{_lib}/%{qt_dirname}/bin/$i %{buildroot}%{_bindir}/${i}4
done
i think you should add "assistant linguist lupdate moc qm2ts uic rcc".
I agree with your choice, but maybe some other developers would find strange
that you forgot to symlink their favorite Qt tool.
And you can symlink qt3to4 without changing its name.
** Why a sub-package for qtconfig, actually? Maybe you have a reason.
** pkgconfig file seem to be hardlinked in %{_libdir}/pkgconfig/ (from
%{qt_dir}/lib/*.pc) instead of being symlinked. Maybe this should be fixed
(even if I doubt that someone has a mount point for %{_libdir}/qt4).
** rpmlint still complains about a lot of things, among:
W: qt4-devel summary-ended-with-dot Development files for the Qt GUI toolkit.
W: qt4-mysql summary-ended-with-dot MySQL drivers for Qt's SQL classes.
W: qt4-odbc summary-ended-with-dot ODBC drivers for Qt's SQL classes.
W: qt4-postgresql summary-ended-with-dot PostgreSQL drivers for Qt's SQL
classes.
W: qt4-sqlite summary-ended-with-dot SQLite drivers for Qt's SQL classes.
Easy fix.
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtNetwork.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtSvg.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtTest.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/Qt3Support.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtSql.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtGui.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtXml.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtCore.pc
E: qt4-devel invalid-directory-reference /usr/lib64/pkgconfig/QtOpenGL.pc
Still -L%{_buildir}/qt-x11-opensource-src-4.1.2/lib in pkg-config files. sed
can fix that.
W: qt4-docs dangling-relative-symlink /usr/lib64/qt4/LICENSE.GPL
doc/LICENSE.gpl
It is a new item. I have seen this link in the spec file. I do not understand.
** Two minor items of my first review are still left without answer:
- The /etc/ld.so.conf.d stuff is not really clear. /etc/ld.so.conf.d is
requires by FC qt on FC-4 and FC-5. And I doubt that qt4 could be accepted for
previous versions of FC. Perhaps you should simplify your spec file by
assuming that /etc/ld.so.conf.d/ is required.
- Your spec file use both %{buildroot} and $RPM_BUILD_ROOT. According to
http://fedoraproject.org/wiki/Packaging/Guidelines#UsingBuildRootOptFlags you
should avoid to mixe the two forms.
Re: comment #30 I'm sticking to %{_libdir}/qt4, as other apps can install stuff in here (like qsa, qwt), and I don't want the dir changing everytime a new version is built. "Mid-air collision": the traffic in this bug starts to be too high for me! :-) My review in comment #31 is for 4.1.2-9. I'm compiling 4.1.2-10... Yeah, especially considerring no one is yet "officially" reviewing this package (at least it's not assigned to anyone). (: OTOH, I don't mind having more eyes on it... Re: comment #31 and -qtconfig subpkg rationale so no collisions on x86_64 for folks who want/need both qt4.i386 qt4.x86_64 (In reply to comment #35) > Re: comment #31 and -qtconfig subpkg rationale > so no collisions on x86_64 for folks who want/need both qt4.i386 qt4.x86_64 ... (!) A real good reason. I had not noticed that. Slammed this one out, so not sure if it builds. (: (I'll update again if my current build fails). Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-11.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-11.src.rpm %changelog * Sat May 13 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-11 - drop optional ld.so.conf.d usage, make mandatory - make %%_bindir symlinks to all %%qtdir/bin stuff (even qt3to4) - pkgconfig files: hardlinks -> relative symlinks, strip -L%{_libdir}/mysql and -L%%{_builddir}/qt-x11-opensource-src-%%version/lib - cleanup/simplify Summary/%%description entries - $RPM_BUILD_ROOT -> %%buildroot, $RPM_BUILD_DIR -> %%_builddir Sure enough, specfile had a small typo(*), I fixed it, respun without incrementing Release. (*) diff: - [-f $i ] && ln -s $i . + [ -f $i ] && ln -s $i . /var/tmp/rpm-tmp.38358: line 49: [-f: command not found
+ rm -rf /var/tmp/qt4-4.1.2-11-root-rineau/usr/lib64/qt4/doc
+ ln
-s ../../share/doc/qt4-devel-4.1.2 /var/tmp/qt4-4.1.2-11-root-rineau/usr/lib64/qt4/doc
+ install -p 'LICENSE.*' /var/tmp/qt4-4.1.2-11-root-rineau/usr/lib64/qt4/
install: cannot stat `LICENSE.*': No such file or directory
See the last line I quoted. Thus, another diff:
for i in ../%{qt_dirname}/lib/*.pc ; do
[ -f $i ] && ln -s $i .
done
+ popd
Kill your build and retry! :-)
Crap, ok. (: (I fixed the qt4-4.1.2-11 links to, but...) Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-12.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-12.src.rpm %changelog * Sat May 13 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-12 - fix typos so it actually builds. note to self: thou shalt not update Review Requests without first actually testing the build. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-13.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-13.src.rpm %changelog * Sat May 13 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-13 - include unpackaged pkgconfig files Since Laurent isn't in fedorabugs group yet, I am happy to
"officially" review this package. ;)
(I'm running thru my full checklist even tho many of these were checked above)
See below - Rpmlint output.
OK - Package name.
OK - Spec file name matches.
- Package guidelines.
OK - Licsense. (GPL/QPL)
OK - License field matches in spec.
OK - License included in files
OK - Spec in american english
OK - Spec legible
OK - Md5sum of source from upstream
18bca010d09b98e94210710047baca0a qt-x11-opensource-src-4.1.2.tar.gz
18bca010d09b98e94210710047baca0a qt-x11-opensource-src-4.1.2.tar.gz.1
OK - Compiles and builds on one arch at least.
(builds in mock on fc5, devel is broken currently)
OK - No Forbidden buildrequires included
OK - All required buildrequires included
OK - Ldconfig in post/postun if including libs.
OK - Owns all directories it creates.
OK - No duplicate files in %files listing.
OK - Permissions on files correct.
OK - Clean section correct.
OK - Macros consistant.
OK - Code not content.
OK - Docs subpackage needed for large documentations.
OK - Docs must not affect runtime.
OK - Header files/libs in a devel package.
OK - Pkgconfig (.pc) files in devel package.
OK - .so files in devel package.
OK - Devel package requires base package.
OK - No .la files.
OK - .desktop file if a GUI app
OK - Doesn't own any files/dirs that are already owned by others.
SHOULD Items:
OK - Subpackages require base package.
OK - builds in mock (fc5 at least).
Issues found:
1. There are some commented out items in the spec, if they aren't used
it might be good to just remove them:
#define x_deps XFree86-devel XFree86-Mesa-libGL XFree86-Mesa-libGLU
...
#rm -f %{buildroot}%{qtdir}/mkspecs/default/linux-g++*
...
#config /etc/profile.d/*
...
2. Do you need the /etc/ld.so.conf.d in Requires(pre) and Requires(post)?
Thats provided by glibc, which I would expect is always present in
the base os...
3. What does this comment refer to?
# Not sure how to use, where to put this, yet -- Rex
4. Does everything build as expected under x86_64 and ppc?
I don't have either of those arch'es here, might be good to test
if someone could do some quick mockbuilds, especially since you
are directly doing some tests that would affect things on x86_64 at least.
5. You have calls to a %debug variable in the build. Perhaps
comment that at the top of the spec in case someone wants to use it?
or just remove it if it's never used.
6. Are static (.a) libs wanted/used by anyone?
(There are 2 in -devel)
7. Current rpmlint output has a few things in it.
E: qt4 script-without-shellbang /usr/lib/qt4/LICENSE.GPL
E: qt4 script-without-shellbang /usr/lib/qt4/LICENSE.QPL
Suggest: change permissions to 644 ?
E: qt4 configure-without-libdir-spec
Suggest: adding '--libdir=%{_libdir}' to ./configure call
E: qt4-designer devel-dependency qt4-devel
E: qt4-docs devel-dependency qt4-devel
Should designer and docs require devel?
There are about a zillion of these (ok, only 6008) :
W: qt4-docs doc-file-dependency
/usr/lib/qt4/examples/draganddrop/fridgemagnets/fridgemagnets libgcc_s.so.1
Suggest: make examples/demos not %doc. Possibly split them
all out into a qt4-examples and/or qt4-demos ?
People typically don't expect doc packages to have lots of requires.
E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-pbuilder/qmake.conf
E: qt4-devel script-without-shellbang
/usr/lib/qt4/mkspecs/macx-pbuilder/Info.plist.app
Suggest: change perms to 644 on those files?
8. Are there no man pages? I don't see any in any of the packages,
comment #2 and #3 makes mention of them.
Starting to look close. ;)
(In reply to comment #42) > 4. Does everything build as expected under x86_64 and ppc? > I don't have either of those arch'es here, might be good to test > if someone could do some quick mockbuilds, especially since you > are directly doing some tests that would affect things on x86_64 at least. I do not use mock (because it seems to takes hours), but a standard build runs correctly on my machine, AMD Turion, with fc5. The package goes to /usr/lib64/qt4 as expected. And there is a symlink /usr/lib64/qt4/lib64 -> lib > 6. Are static (.a) libs wanted/used by anyone? > (There are 2 in -devel) libQtUiTool is used in the example at: http://doc.trolltech.com/4.1/designer-calculatorbuilder.html It is mandatory for the module QtUiTools of Qt-4: http://doc.trolltech.com/4.1/qtuitools.html libAssistantClient is for the Assistant module: http://doc.trolltech.com/4.1/qtassistant.html Maybe these two minors libs are too new in Qt, and developers didn't want to freeze them (all qt-4 versions are supposed to be binary and source compatible). > E: qt4 configure-without-libdir-spec > > Suggest: adding '--libdir=%{_libdir}' to ./configure call Qt's configure is not a GNU configure. The option --libdir does not exists. However, -libdir (one slash) exists. (Please to see this bug assigned! Hint: three requests depend on qt4, and one of them is mine...) A warning, at the very end of the build: + desktop-file-install --vendor=qt --dir /var/tmp/qt4-4.1.2-13-root-rineau/usr/share/applications --add-category=X-Fedora /home/rineau/RPM/SOURCES/designer4.desktop /var/tmp/qt4-4.1.2-13-root-rineau/usr/share/applications/qt-designer4.desktop: warning: file contains key "MapNotify", usage of this key is not recommended, since it has been deprecated Created attachment 128986 [details]
Small patch to qt4-4.1.2-13.spec
Yet another remark (sorry for the spam): to be coherent, you should apply the
patch attached.
Comment on attachment 128986 [details]
Small patch to qt4-4.1.2-13.spec
typo (Need to sleep. 4:00am at Paris. See you tomorrow.)
Re: comment #46. I don't see the need for this patch. Logically, it is the same with or without it. Re: comment 44 I'll remove MapNotify. Re: comment 42 > 2. Do you need the /etc/ld.so.conf.d in Requires(pre) and Requires(post)? Technically, yes, it guarantees correct install order (say, during an initial install). In practice, it's unlikely that not having it would ever cause problems. > 3. What does this comment refer to? > # Not sure how to use, where to put this, yet -- Rex The item right below it: Source1: qt.conf The qt documentation mentions the use of qt.conf to set qt options, and I'd like to be able to set some global ones, but it wasn't clear to me where to put it. > Should designer and docs require devel? Yes, they're both addons to the base development install. qt(3)'s -designer is the same, and the docs used to be in -devel, but I've split them off. > 8. Are there no man pages? Nope. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-14.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-14.src.rpm %changelog * Sat May 14 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-14 - remove MapNotify from .desktop file(s). - install -m644 LICENSE.* - docs: don't mark examples as %doc - drop unused %%debug macro So I have an lite modification for your spec file to safe mutch compiling time.
Because the examples are not compiled.
replay make ..
with this:
make %{?_smp_mflags} sub-src
make %{?_smp_mflags} sub-tools
make INSTALL_ROOT=%{buildroot} sub-src-install_subtargets
make INSTALL_ROOT=%{buildroot} sub-tools-install_subtargets
make INSTALL_ROOT=%{buildroot} install_htmldocs
make INSTALL_ROOT=%{buildroot} install_qmake
make INSTALL_ROOT=%{buildroot} install_mkspecs
make INSTALL_ROOT=%{buildroot} install_translations
(In reply to comment #47) > Re: comment #46. > I don't see the need for this patch. Logically, it is the same with or without it. If %{_lib} can only have to two values "lib" or "lib64", I agree. But perhaps one day an arch will have another value. "multilib", for example (if the multilib feature of MacOS-X comes to other OS). Actually, it is really a very minor issue. I do not really care. :-) # drop -fexceptions from $RPM_OPT_FLAGS RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | sed 's|-fexceptions||g'` # use $RPM_OPT_FLAGS sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/*/qmake.conf Is not good. Better only change the flag for compiler file for the gcc. And add an menu entry for the linguist tool. 4.1.2-14 does not build: + -shared -no-exceptions -largefile -qt-gif -system-zlib -system-libpng -system-libjpeg -plugin-sql-mysql -I/usr/include/mysql -L/usr/lib64/mysql -plugin-sql-psql -plugin-sql-odbc -plugin-sql-sqlite -cups -sm -stl -xcursor -xinerama -xshape -xrandr -xrender -xkb -fontconfig -tablet /var/tmp/rpm-tmp.66860: line 51: -shared: command not found error: Bad exit status from /var/tmp/rpm-tmp.66860 (%build) :-( @@ -171,7 +171,7 @@ %else -platform linux-g++ \ %endif - -release + -release \ -shared \ -no-exceptions \ -largefile \ missing \ after -release Re: comment #51 > Is not good. Better only change the flag for compiler file for the gcc. Why do you say that? If not, any qt app that uses qmake won't get $RPM_OPT_FLAGS. qmake wil only look at this 3 files when using the gcc mkspecs/linux-g++/qmake.conf mkspecs/linux-g++-32/qmake.conf mkspecs/linux-g++-64/qmake.conf But with your code you will change the lines for the other compiler to. And the $RPM_OPT_FLAGS are only for the gcc. And not for example for the icc. (In reply to comment #37) > %changelog > * Sat May 13 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-11 [...] > - pkgconfig files: hardlinks -> relative symlinks, strip -L%{_libdir}/mysql > and -L%%{_builddir}/qt-x11-opensource-src-%%version/lib Actually, I do not really understand why you trip -L%{_libdir}/mysql from pkgconfig file. It might be a FE rule that I am not aware. (In reply to comment #48) > %changelog > * Sat May 14 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-14 [...] - docs: don't mark examples as %doc ** rpmlint has new warnings after this change: W: qt4-docs devel-file-in-non-devel-package /usr/lib64/qt4/examples/tools/plugandpaint/plugindialog.h for every header in -examples/. Furthermore, the package guidelines states that a file marked as %doc should not be required by the package: "If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present." (Maybe future versions of rpm will allow to uninstall %doc files, and %lang files.) However, %{qtdir}/bin/qtdemo (in qt4-devel) depends on the headers and sources in %{qtdir}/examples and %{qtdir}/demo. IMHO nothing should be %doc in the -docs subpackage (as in tetex-doc in fc). %{qtdir}/bin/qtdemo should go in qt4-docs, I think. ** Subpackage -docs should be named -doc The packaging guidelines and the review guidelines do not agree on the name of documentation subpackage. "Tom 'spot' Callaway" <tcallawa> has admitted on the FE list that it was a typo in the review guidelines: a documentation subpackage should be named -doc. ** There are dandling symlinks in %{_bindir}. It seems that there are some binaries in the bin/ subdirectory of Qt build tree that are not installed. And qt3to4 got the suffix. Proposed patch: @@ -250,10 +250,10 @@ # Make symlinks in %%_bindir mkdir -p %{buildroot}%{_bindir} -pushd bin +pushd %{buildroot}%{qtdir}/bin for i in *; do SUFFIX=4 - [ "$1" == "qt3to4" ] && SUFFIX="" + [ "$i" == "qt3to4" ] && SUFFIX="" ln -s ../%{_lib}/%{qt_dirname}/bin/$i %{buildroot}%{_bindir}/${i}${SUFFIX} done popd Re: comment #56 > I do not really understand why you trip -L%{_libdir}/mysql > from pkgconfig file Because it's not (really) needed. Re: -doc subpkg naming Yeah -doc is the way to go. We're starting to find quite a few interesting interdependancies between -devel and -doc. qtdemo was one (it depended on the demos/examples from -doc, so I was moving it to -doc), then I found assistant (in -devel) tries to auto-load qt documentation on startup (and fails, obviously, if -doc/-docs isn't installed). I'm beginning to doubt the wisdom of even doing a -doc subpkg... who knows how many more interdendancies may exist. At the moment, I'm leaning toward dropping the notion of a -doc subpkg, and move it all (back) to -devel (mostly for sake of simplicity). Comments/opinions? Actually, libQtAssistant.a search assistant in the path. The following patch
is required:
--- qt-x11-opensource-src-4.1.2/tools/assistant/lib/qassistantclient.cpp~
2006-03-20 14:04:38.000000000 +0100
+++ qt-x11-opensource-src-4.1.2/tools/assistant/lib/qassistantclient.cpp
2006-05-15 15:42:07.000000000 +0200
@@ -170,7 +170,7 @@
else {
QFileInfo fi( path );
if ( fi.isDir() )
- assistantCommand = path + "/assistant";
+ assistantCommand = path + "/assistant4";
else
assistantCommand = path;
}
One problem: assistant should perhaps go to qt4 (not -devel), or a -assistant
sub package (I would prefere the latter), because of libQtAssistant.
As regard the -L%{_libdir}/mysql, sorry for that: I had not noticed that
-lmysql was not in that .pc file.
As regards the necessity to have a -doc subpackage, du(1) shows:
$ du -s /usr/lib64/qt4/{examples,demos,lib,plugins,include,doc}/. | sort -n
2636 /usr/lib64/qt4/plugins/.
4392 /usr/lib64/qt4/demos/.
13596 /usr/lib64/qt4/examples/.
13828 /usr/lib64/qt4/lib/.
15892 /usr/lib64/qt4/include/.
61756 /usr/lib64/qt4/doc/.
It seems mandatory.
Created attachment 129058 [details] Patch for qt4-4.1.2-14.spec Before your comment #57, I was compiling and testing a home-made qt-4.1.2-15. here is the patch I used. It does solve the assistant problem. Re: comment #59 Can you explain your rationale for the patch and why assistant should be in qt4 and not qt4-devel? What about my comment #58 about assistant giving errors if -doc is not installed? I'm against an -assistant subpkg, I don't see any need/value in that. I think I'm just going to roll 4.1.2-16 with -doc bits mashed back into -devel to avoid all these messy interdependancies for now. libQtAssistant.a is a library that includes only one class, named
QtAssistantClient. Its purpose is to permit to launch the Qt Assistant, with
special communication features between the application and the Assistant.
However, the implementation of it QtAssistantClient searches assistant in the
$PATH, and not in the Qt directory.
An application compiled with libQtAssistant will launch "assistant" from the
path.
I do not know if there already exist some third-party application compiled
with libQtAssistant. qtdemo uses it. On my system, there are two problems:
-Â if qt4-devel is not installed, the Qt4 assistant is not installed,
-Â my $PATH does not contain /usr/lib64/qt4/bin, and the Qt3 assistant is
launched instead of the Qt4 one. And it fails to display the documentation
(not in the adequate format).
The libQtAssistant should search for "assistant4", which is in %{_bindir}/.
That's why IMHO, if the qt4 package ships libQtAssistant.a, the assistant tool
should be move from qt4-devel to qt4 itself, or to a special small package
qt4-assistant (like qt4-config), as its normal use requires qt4-doc.
Thanks for the explanation. With that in mind, -doc still makes sense, and we can add -assistant to -doc, with Provides: qt4-assistant, avoiding making -assistant Requires: -doc, and change -doc's deps from Requires: qt4-devel to Requires: qt4 Re: comment #59 patch That looks wrong to me, should it be this instead: --- qassistantclient.cpp.assistant4 2006-03-20 07:04:38.000000000 -0600 +++ qassistantclient.cpp 2006-05-15 10:41:41.000000000 -0500 @@ -166,7 +166,7 @@ : QObject( parent ), host ( "localhost" ) { if ( path.isEmpty() ) - assistantCommand = "assistant"; + assistantCommand = "assistant4"; else { QFileInfo fi( path ); if ( fi.isDir() ) Since it uses the system path (only) if the provided path is empty. If path "isDir" one would hope that an app author would be wise enough to provide %qtdir/bin and not %bindir. Maybe the package qt4 should ship a file %doc README.fedora to explain were are things, in the qt4-* packages. :-) (In reply to comment #64) > Re: comment #59 patch > That looks wrong to me, should it be this instead: > if ( path.isEmpty() ) > - assistantCommand = "assistant"; > + assistantCommand = "assistant4"; > else { Yes, of course. I understood the code like you, but I made a stupid mistake. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-16.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-16.src.rpm %changelog * Sun May 15 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-16 - set/use RPM_OPT_FLAGS only for our platform - (really) don't give %%_bindir symlink for qt3to4 another "4" suffix - don't add 4 suffix to uic3, rcc (they don't conflict with qt(3)-devel) - -devel: add linguist.desktop - -doc: move assistant here, Provides: %%{name}-assistant, add assistant.desktop - -doc: add qtdemo.desktop - -doc: Requires qt4 (instead of qt4-devel) - assistant4.patch: search for assistant4 instead of (qt3's) assistant in $PATH - -qtconfig: add qtconfig.desktop - updated %%sumaries to mention where (some) tools are, including assistant, linguist, qtdemo Trolltech will release Qt 4.1.3 shortly. I think you shut wait 3 or 4 days for Qt 4.1.3. Trolltech will release Qt 4.1.3 shortly. I think you shut wait 3 or 4 days for Qt 4.1.3. The changes cann be view here: http://www.trolltech.com/developer/notes/changes/changes-4.1.3/ (In reply to comment #67) Nice changelog! A lot of things to check. I have compiled it without error nor warning. rpmlint still says: W: qt4-devel dangling-relative-symlink /usr/lib64/qt4/doc ../../share/doc/qt4-devel-4.1.2 I think that this doc symlink should be in the -doc subpackage. Another rpmlint complain: W: qt4-doc devel-file-in-non-devel-package /usr/lib64/qt4/demos/textedit/textedit.h should be ignored, I think. > I think that this doc symlink should be in the -doc subpackage.
Include a symlink to a dir that doesn't nessesarily exist? (Remember, -doc
doesn't Requires: qt-devel anymore).
I'll update to 4.1.3 as soon as it is released, whether that is before or after
package is APPROVED. Please don't postpone review(s) for that.
%{_datadir}/doc/qt4-devel-4.1.2/ is not owned by any package, actually. But
qt4-doc fills it by creating %{_datadir}/doc/qt4-devel-4.1.2/html/. Maybe
something is wrong, actually. But I think that the symlink %{qtdir}/doc should
be in -doc, because the directory pointed by it (whatever it is) is filled
only by -doc.
OK, you have a point. If it's not *in* qt4-devel anymore, there's not much
point putting it at %{_datadir}/doc/qt4-devel-*
Any opinions on where to put qt_docdir? I think we can agree it, and %qtdir/doc
symlink, should be owned by -doc. How about:
%define qt_docdir %{_datadir}/doc/qt4-doc-4.1.2/html/
?
Sounds sane to me MUST: the desktop files must state that it is Qt 4 tools. In my KDE menu, I've got to identical entries for several tools, now. Some icons, used by the desktop files, seem to belong to the kdebase package. I do not know what would happen if this package was removed (would it find some other icons, or non icons at all?). (In reply to comment #74) > Any opinions on where to put qt_docdir? I think we can agree it, and %qtdir/doc > symlink, should be owned by -doc. How about: > %define qt_docdir %{_datadir}/doc/qt4-doc-4.1.2/html/ > ? Why not "%define qt_docdir %{_datadir}/%{qt_dirname}/doc"? IMHO it seems more simple. True, (assuming you *really* mean %qtdir/doc), that's the default location, but (I think) the point is to try to find an ideal location under %_datadir/doc somewhere. Even %{_datadir}/%{qt_dirname}/doc is OK, and I think I like it better than
_docdir/qt4-doc-%version because it won't move on every upgrade.
Just occurred to me looking at other config options... would it be crazy to try
something like:
./configure \
-headerdir %{_includedir} \
-datadir %{_datadir} \
-libdir %{_libdir} \
-sysconfdir %{_sysconfdir} \
?
Looked at Mandriva's qt4 pkg, they use -docdir %_docdir/%%name-%%version I think I'll go with that. Anyone have an inclination whether we ought to build/include lib_debug libs too, using ./configure -debug-and-release instead of ./configure -release ? No biggie. Clearly if/when they are included, they'd be in their own subpkg, so it should be easy to add later if there is demand. (most bits from -18 borrowed from looking at Mandriva's qt4 rpm) Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-18.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-18.src.rpm %changelog * Tue May 16 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-18 - %%_bindir symlinks: qtconfig4 -> qt4config, qtdemo4 -> qt4demo - -libdir %%qtdir/%%_lib, simplifies %%_lib != lib case - -docdir %%_docdir/%%name-%%version - build shared versions of libQtAssistantClient,libQtUiTools too - strip extraneous -L paths, libs from *.prl files too * Tue May 16 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-17 - .desktop: Qt -> Qt4, and Comment= (where missing) - -devel: include -designer here, Obsoletes/Provides: %%name-designer. It's small, simplifies things... one less subpkg to worry about. - -doc: include %%qtdir/doc symlink here - -docdir %%_docdir/%%name-doc-%%version (In reply to comment #80) > Just occurred to me looking at other config options... would it be crazy to try > something like: > ./configure \ > -headerdir %{_includedir} \ > -datadir %{_datadir} \ > -libdir %{_libdir} \ > -sysconfdir %{_sysconfdir} \ > ? It's the policy of Debian, AFAIK. It seems to be possible, and quite easy. Re: comment #84. Great. The only drawback is that doing so makes parallel installs impossible (or at least a lot harder). No biggie. I'll play around with that to consider later... let's see if we can get this approved in < 100 comments. (: (In reply to comment #83) > - build shared versions of libQtAssistantClient,libQtUiTools too Real bad. As I said in comment #43, the Qt developers will not preserve the binary compatibility. The soname is incorrect, with theses two patches. In comment #43, you sounded unsure and seemed to be speculating about binary compatibility. Well, even if it's remotely possible, I guess we'll have to stick with upstream and their use of these 2 static libs. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-19.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-19.src.rpm %changelog * Tue May 16 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-19 - drop libQtAssistantClient,libQtUiTools shlib patches (In reply to comment #87) > In comment #43, you sounded unsure and seemed to be speculating about binary > compatibility. Well, even if it's remotely possible, I guess we'll have to > stick with upstream and their use of these 2 static libs. I have checked. As far as I understand the makefiles, the soname will be libQtFoobar.so.4 for each library, even for the two that should have more restrictive soname. I cannot assure you that the binary compatibility will be break, but it could, as Qt developers have chosen to make them static. Needed patch to compile release -19:
@@ -276,9 +276,8 @@
*)
LINK=${i}4
;;
-
- ln -s ../%{_lib}/%{qt_dirname}/bin/$i %{buildroot}%{_bindir}/${LINK}
esac
+ ln -s ../%{_lib}/%{qt_dirname}/bin/$i %{buildroot}%{_bindir}/${LINK}
done
popd
(diff is stupid: it is the "esac" that needs to move.)
(using the spec/src.rpm from comment #88 and the patch in comment #90) Hopping into the wayback machine for comment #47: :) >> 3. What does this comment refer to? >> # Not sure how to use, where to put this, yet -- Rex >The item right below it: >Source1: qt.conf >The qt documentation mentions the use of qt.conf to set qt options, and I'd like >to be able to set some global ones, but it wasn't clear to me where to put it. From looking around, it looks like this is a file that an application can use to override the default paths that qt uses to look for things. So, I think it's safe for this package to not ship one. From comment #56: >(Maybe future versions of rpm will allow to uninstall %doc files, and %lang files.) The future is here now. ;) rpm --excludedocs From comment #58: >We're starting to find quite a few interesting interdependancies between -devel >and -doc. qtdemo was one (it depended on the demos/examples from -doc, so I >was moving it to -doc), then I found assistant (in -devel) tries to auto-load >qt documentation on startup (and fails, obviously, if -doc/-docs isn't >installed). I'm beginning to doubt the wisdom of even doing a -doc subpkg... >who knows how many more interdendancies may exist. At the moment, I'm leaning >toward dropping the notion of a -doc subpkg, and move it all (back) to -devel >(mostly for sake of simplicity). > >Comments/opinions? What about just putting the doc/html area in doc, and both demos and examples back in devel. That would move off a large amount of docs and would get rid of all these wacky requirements. The doc subpackage would just have html stuff in it. assistant and qtdemo could move back to devel. This is much more what a doc package should be. Examples and demos should be things you need devel for to use anyhow, IMHO. Thoughts? From comment #58: > Great. The only drawback is that doing so makes parallel installs impossible > (or at least a lot harder). No biggie. I'll play around with that to consider > later... let's see if we can get this approved in < 100 comments. (: Thats too bad. Having it parallel installable would be nice. :( Not a blocker though I guess. Looking at the -19 spec I don't see you using -headerdir, -datadir, and -sysconfdir, just -libdir. So does that mean it's still easily parallel installable? New items: 1. On the desktop-install, shouldn't the vendor be: 'fedora'? http://fedoraproject.org/wiki/Packaging/Guidelines#desktop 2. It still doesn't build for me even with the patch from comment #90. I get: RPM build errors: File not found by glob: /var/tmp/qt4-4.1.2-19.fc6-root-mockbuild/usr/bin/qt*config* File not found: /var/tmp/qt4-4.1.2-19.fc6-root-mockbuild/usr/bin/qt3to4 File not found by glob: /var/tmp/qt4-4.1.2-19.fc6-root-mockbuild/usr/bin/rcc* File not found: /var/tmp/qt4-4.1.2-19.fc6-root-mockbuild/usr/share/doc/qt4-4.1.2/html File not found by glob: /var/tmp/qt4-4.1.2-19.fc6-root-mockbuild/usr/bin/qt*demo* Re: comment 91 >What about just putting the doc/html area in doc, and both demos and > examples back in devel. That would move off a large amount of docs > and would get rid of all these wacky requirements. The doc subpackage > would just have html stuff in it. assistant and qtdemo could move back to devel. I guess you missed the part about assistant auto-loading docs on startup (comment #57), so assitant and doc/html are tied together. qtdemo I don't see as something strictly needed in a development environment, so, IMO should stay in -doc, but I don't feel strongly about that. > I don't see you using -headerdir, -datadir, and -sysconfdir Not yet, though we're using -libdir (though trivially, for a different reason) > On the desktop-install, shouldn't the vendor be: 'fedora'? That's not a hard/fast rule. It's more important, long-term, that .desktop files reflect upstream and *never* be renamed, so, I chose qt4 instead. > 2. It still doesn't build for me even with the patch from comment #90. Yeah, turns out you can't mix hard-coding the docdir path *and* use %doc pointing to the same place (because using %doc rm -rf everything there first). Fix: set qt_docdir to something else, like back to %%_docdir/%%name-doc-%%version Re: comment #92: Oh yeah, I did see that, just forgot about it. ;( So, without the -headerdir/-datadir/-sysconfdir is the package currently still parallel installable (x86/x86_64)? I thought there was a hard requirement for vendor on desktop files to be 'fedora', but I can't find it anywhere now, so there must not be. ;) Can you generate a new spec/src.rpm that builds with the docdir fixed? I think we are close now... perhaps we will even get there before 100 comments.;) (In reply to comment #93) > So, without the -headerdir/-datadir/-sysconfdir is the package currently > still parallel installable (x86/x86_64)? I'll try to double-compile the package, to check. I'll wait until the spec file is stabilized. Because it takes one hour to compile, on my computer (and also 1GB). In qt4-4.1.2-19.spec, the %{qtdir}/lib symlink is missing (if %{_lib}!="lib"), and a lot of lines of %install fail because of that. > So, without the -headerdir/-datadir/-sysconfdir is the package currently
> still parallel installable (x86/x86_64)?
By parallel installable, I meant installing different qt4 versions (same arch),
ie, qt-4.1.2 and qt-4.2.0 on the same box, not multilib (x86/x86_64). Multilib
installs will(should!?) be fine either way.
I'll make sure qt4-4.1.2-20 actually builds before posting mods.
I think sub-packages should own the directories in which they install files. I tried install then remove all qt4 package (a qt4-4.1.2-20.spec of my own), and some directories remain: /usr/lib64/qt4 /usr/lib64/qt4/bin /usr/lib64/qt4/lib64 /usr/lib64/qt4/plugins Other problems:
-Â On my builds, -L%{_builddir}/qt-x11-opensource-src-%{version}/lib is still
in some pkgconfig file. Maybe use "sed -e 's|...||g'" instead of "sed -e
's|...||'"
-Â %{qtdir}/doc does not link to the right directory.
(sorry for comment #98, ignore it) My own spec file: http://www.di.ens.fr/~rineau/Fedora/qt4-4.1.2-20rineau.spec Its fixes comment #97, and several x86_64 spec bugs. However, some directories are not properly owned, yet: the one I pointed out in comment #96, and of %{_datadir}/qt4 and %{_datadir}/qt4/doc Now 4.1.3 is out. ftp://ftp.trolltech.com/qt/source Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-20.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.2-20.src.rpm %changelog * Fri May 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.2-20 - fix some unowned dirs - try harder to purge %%builddir from .pc,.prl files - -docdir %%_docdir/%%name-doc-%%version, since we use %%doc macro in main pkg - -doc: own %%qt_docdir - use qt4-wrapper.sh to ensure launch of qt4 versions of apps that (may) overlap with those from qt3 - use %%qtdir/%%_lib in ld.so.conf.d/*.conf files too (In reply to comment #101) > http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.2-20.spec * -libdir %{qtdir}/%{_lib} but after that the symlink lib->%{_lib} is missing, if %{_lib}!="lib". It makes the build fail in %install. * -docdir %{qt_docdir}/ => extra "/" Re: comment #102 > but after that the symlink lib->%{_lib} is missing So? I see no problem. > It makes the build fail in %install. It built fine for me in mock. ?? > * -docdir %{qt_docdir}/ > => extra "/" Again, so? Problem being? (In reply to comment #103) > Re: comment #102 > > but after that the symlink lib->%{_lib} is missing > So? I see no problem. > > It makes the build fail in %install. > It built fine for me in mock. ?? Even if %{_lib}=="lib64"? For example, the following will fail to find any pkgconfig file: for i in ../%{qt_dirname}/lib/*.pc ; do [ -f "$i" ] && ln -s $i . done Because ../%{qt_dirname}/lib/ does not exist (whereas ../%{qt_dirname}/lib64 does). > > * -docdir %{qt_docdir}/ > > => extra "/" > > Again, so? Problem being? The build shows some "//" but it may not be important. I do not know. From the beginning I make verbose reports of what I see. Maybe I should calm down. :) Thanks for the clarification. I didn't see it because I don't have a x86_64 box. I fixed pkgconfig link bits to reference %qt_dirname/%%_lib instead. qt-4.1.3-1 update coming as soon as my mock build finishes OK. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.3-1.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.3-1.src.rpm %changelog * Fri May 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.3-1 - 4.1.3 - %%qtdir/lib/*.pc -> %%qtdir/%%_lib/*.pc (hopefully, the last hardcoded reference to %%qtdir/lib) Created attachment 129744 [details]
Patch for qt4-4.1.3-1.spec (lib vs. %{_libs} + owning of directories by subpackages)
There was a "*/lib" left. And %{qtdir}/plugins/ and %{qtdir}/{_lib}/ should be
owned by subpackages that install things in too.
Created attachment 129745 [details]
(updated) Patch for qt4-4.1.3-1.spec (lib vs. %{_libs} + owning of directories by subpackages)
I forgot to own %{qtdir} itself, in subpackages.
The patch attached is for qt4-4.1.3-1.spec.
Some pkgconfig files refere to "-lQtGui64". I do not understand. Here they are: /usr/lib64/qt4/lib64/Qt3Support.pc /usr/lib64/qt4/lib64/QtGui.pc /usr/lib64/qt4/lib64/QtSvg.pc /usr/lib64/qt4/lib64/QtOpenGL.pc referes to "-lQtOpenGL64". "ld -lQtGui64" gives an error. Some .prl files have errors too... Created attachment 129761 [details] (v3) Patch for qt4-4.1.3-1.spec (lib vs. %{_libs} + owning of directories by subpackages) I found the bug of comment #109: when sed removes " -L/usr/X11R6/lib", on x86_64, it leaves "64". :-( I hope this is the last "lib64" issue. Thanks. Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.3-2.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.3-2.src.rpm %changelog * Sat May 20 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.3-2 - -mysql: use mysql_config for setting cflags/ldflags. - -mysql: BR: mysql-devel > 4.0 * Sat May 20 2006 Laurent Rineau <laurent.rineau__fc_extra> - Fix the last reference to %{qtdir}/lib: use %{_lib} instead of "lib". - Fix the ownership of subpackages: they need to own parents of directories they install files in. qt4-4.1.3-2.spec fails to build, on x86_64: the configure line is: ./configure -v -no-rpath -prefix /usr/lib64/qt4 -libdir /usr/lib64/qt4/lib64 -docdir /usr/share/doc/qt4-doc-4.1.3 -platform linux-g++-64 -release -shared -no-exceptions -largefile -qt-gif -system-zlib -system-libpng -system-libjpeg -plugin-sql-mysql -I/usr/include/mysql -plugin-sql-psql -plugin-sql-odbc -plugin-sql-sqlite -cups -sm -stl -xcursor -xinerama -xshape -xrandr -xrender -xkb -fontconfig -tablet As you can see, mysql_ldflags seems empty! However: rineau@schtroumpfette ~/RPM $ mysql_config --libs | perl -pi -e "s, -l/? \S+,,g" -L/usr/lib64/mysql -L/usr/lib64 Maybe this is the %() that should be $(), as for %mysql_include. I do not know these two syntaxes. What is "%global", instead of "%define"? With these three lines, it seems to find the correct flags:
%global mysql_include $(mysql_config --include || echo
"-I%{_includedir}/mysql")
%global mysql_libs $(mysql_config --libs || echo "-L%{_libdir}/mysql")
%global mysql_ldflags $(echo %{mysql_libs} | perl -pi -e "s, -l/?
\\\S+,,g")
See the extra quote of "\" in mysql_ldflags.
Created attachment 129774 [details]
Mysql patch to qt4-4.1.3-2.spec
Here is the corresponding patch. The build qt4-4.1.3-2 seems good.
Spec Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/qt4-4.1.3-3.spec SRPM Name or Url: http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/qt4-4.1.3-3.src.rpm %changelog * Sun May 21 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.3-3 - fix %%mysql_libs macro (using the spec/rpm from comment #115) - Builds ok in mock for fc5 at least. - Still some rpmlint warnings, but much reduced. Most of the rest can be ignored. 1. These might need attention: E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-xcode/qmake.conf E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-xcode/Info.plist.app E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-pbuilder/qmake.conf E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-pbuilder/Info.plist.app Might need permissions to be 644? Or do we even need the macx apps packaged? 2. Should all the subpackages own /usr/lib/qt4? The main package owns it, and they all require that package. Is there a reason for all of them to own it? I still am looking through the devel package to doublecheck all the .pc files and libs... hopefully will get that done late tonight or tomorrow. 3. Ownership of /usr/lib/qt4/plugins and /usr/lib/qt4/plugins/sqldrivers also looks fishy... shouldn't those be owned by the base qt4 package only? currently the base and all subpackages own that dir. Since all the sub packages require the base qt4, the dir would always be there... (The core package has nothing owning /usr/lib/qt4/plugins/sqldrivers, which isn't right either) All the .pc files look good. Libs look good from here. I'm not seeing any blockers aside from the 2 minor issues in comment #116 and the one mentioned here... Laurent, do you see anything further on x86_64? (In reply to comment #116) > 2. Should all the subpackages own /usr/lib/qt4? The main package owns it This my fault. rpm has a bug, and if subpackages do not own such common directories, the latter remain when one uninstall the whole package with its subpackages. I did not know it was a rpm bug that is fixed in CVS. I wrote a mail to the FE-list, about this subject. It appears that one can own the directories this way, but it is not a must. Quote of the reply of Ville Skyttä <ville.skytta>: ------------------------------------------------------------------- The guideline kind of assumes that rpm does proper erasure ordering, but as far as I know, no FC version ships with such rpm.  Strictly speaking, there are *lots* of packages around that may cause empty dirs being left behind because of that (everything except "filesystem"?), and if the fix for #89500 turns out as expected, the affected ones would be instantly fixed without making any changes to packages and multi-ownership of dirs (for this particular purpose) would become zero-value specfile/rpmdb/repodata cruft. In my opinion that's why the guideline should hold.  Micro-managing the dirs in a few packages here and there doesn't help much at all in the big picture. -------------------------- end of quote ---------------------------- (In reply to comment #117) > 3. Ownership of /usr/lib/qt4/plugins and /usr/lib/qt4/plugins/sqldrivers also > looks fishy... Again: added after my demand. It could be fixed, or keep this way. > Laurent, do you see anything further on x86_64? No. That's why I stopped spamming this bug after comment #115! ;-) I do not see blockers. As regards this point: (In reply to comment #116) > 1. These might need attention: > > E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-xcode/qmake.conf > E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-xcode/Info.plist.app > E: qt4-devel script-without-shellbang /usr/lib/qt4/mkspecs/macx-pbuilder/qmake.conf > E: qt4-devel script-without-shellbang > /usr/lib/qt4/mkspecs/macx-pbuilder/Info.plist.app > > Might need permissions to be 644? Or do we even need the macx apps packaged? The only needed directories in %{qtdir}/mkspecs are maybe linux-g++*. However, the install: rule of Qt makefiles install "make-specs" for all platforms. Maybe it can be usefull for cross-compiling or something like that. IMO, it should be keeped. I can help a Qt developer to debug a problem that occurs only on other platforms. Maybe. :-\ The permissions could be easily fixed. However, this is not a blocker. I don't see any further blockers... If you want to take a look at the non blocking issues in the last few comments before you import that would be great. Thanks for all your hard work on packaging this up and reviewing... This package is APPROVED. Don't forget to close this bug with NEXTRELEASE once you have imported and built the package. Thanks everyone for the excellent review(s)! Imported. FC-4, FC-5 branches requested. Queued fc6/devel build after the following update: %changelog * Wed May 24 2006 Rex Dieter <rexdieter[AT]users.sf.net> 4.1.3-4 - move (most) %%dir ownership (back) to main pkg Here's a few bugs for possible qt4 packaging enhancements, comments? (make them in the corresponding bug please). * bug #196513 â qt4: include debug libraries (almost done) * bug #196899 â qt4: split-out gui(x11) and non-gui bits * bug #196901 â qt4: make FHS-friendly (ie, put libs in %_libdir, headers in %_includedir) Package Change Request ====================== Package Name: qt4 Updated Fedora CC: than Updated EPEL CC: than done Package Change Request ====================== Package Name: qt4 Updated Fedora Owners: than,rdieter.edu Updated EPEL Owners: than,rdieter.edu Updated Fedora CC: Updated EPEL CC: comment: move than from CC: to (primary) Owner: cvs done. Package Change Request ====================== Package Name: qt New Branches: F-9 cvs done. |