| View previous topic :: View next topic |
| Author |
Message |
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
 Posted: Sun Jan 06, 2008 8:07 pm Post subject: Qt Copy ebuilds: Qt v3/v4. Updated: 20080115!!! |
 |
|
Hi all,
Disclaimer:
Please report bugs to this thread and not bugs.g.o. The Gentoo developers do not support this at this moment in time. If some part of Qt Copy is messing up your program, first try to recompile that program. If that does not work, then recompile Qt with out the qt-copy use flag and recompile the troublesome program. If that does help the problem, then you can talk to the KDE devs at #kde on Freenode since they support Qt Copy, but if that does not help, then there is a problem with the program you are using. Only file bugs in bugs.g.o if you have compiled the program against a Gentoo's Qt meaning that you just disable the qt-copy use flag and recompile Qt. That is why I have the use flag and why I left Gentoo's Qt part fully intact. Thanks.
Intro
I posted in the KDE4 Overlay thread that I had a Qt 4.3.3 Qt Copy ebuild. I decided to make ebuilds for the stable versions of Qt as well. I have ebuilds for: qt-3.3.8-r4 (stable), qt-4.3.2-r1 (stable), and qt-4.3.3 (unstable but required for KDE 4.0.x).
What is "New and Improved" about these?
Previously, all Qt Copy ebuilds used the script apply-patches that is included with the Qt Copy download from KDE SVN. Running this script is not very Gentoo-like, so I remade the ebuilds with using portage technology to apply all the patches, thus they are now Gentoo-ized.  I had to hand test each patch in order to make it work with Gentoo's patches for Qt. The apply-patches script just tested to see if each patch succeeded and if it didn't, it didn't apply it, so a lot of times, the patches were never adjusted. I was once the maintainer of the pertty patches and I included Qt Copy ebuilds and I was even guilty of not test all the patches and just relied on the script. Bad me. I had to update Qt Copy a few times, and never thought about adjusting the patches.
Also, if you do not select the qt-copy use flag, then you will get the Qt that the Gentoo devs put together. All their patches are fully intact, so if there are issues, then you can turn off the qt-copy use flag and recompile to see if the issue is still there. I was guilty of just removing a patch that the Gentoo devs put in that was similar to a Qt Copy patch and then bumping the revision. Now, I remove Qt Copy patches that are similar to what the Gentoo devs put in teh Qt ebuilds.
What is this Qt Copy thing anyways?
Qt Copy is a set of patches put together by the KDE Devs. They tune Qt to their needs: some are bug fixes and some are speed improvements. Like for example, I have KDE 4.0.0 installed and I use to have it compiled against the regular Qt, but then I compiled it against Qt Copy and I noticed a speed increase in the rubberband effect and other effects too. I have a P4 2 GHz, so I need all the help I can get that saves me CPU cycles.
Back in the KDE3 days, Qt Copy added a lot of enhancements to Qt and made possible most of the things in the pertty patchset. They added a number of fixes as well, and most of those fixes were included into Qt4 by the TrollTech devs. There are not a lot of patches for the Qt4 line compared to the Qt3 line. However, they are still good patches that tweak Qt just a little bit more.
Updates:
20080115:
Qt Copy for 3.3.8-r4 has a brand new patch just submitted today. It's to use the new xinerama version. Also, there are 3 other patches that I forgot to include in the previous release. This should fix any errors people might have had with the rubberband. Sorry about that.
Qt Copy for 4.3.3 has one new patch to prefer xrandr over xinerama. If you do not care about these or use them, then you do not need to update. I have both these new updates installed and all I can say is that I regret leaving out those three patches, because KDE3 with the new KDE patches I have (to be released later after testing) really fly on these and work flawlessly now. It's brilliant. KDE3 now how a lot of eyecandy like KDE4 and a working Kickoff on the new revision of Kicker. ^^ Stay tuned for a release on that. The download link has been updated. Still no layman overlay file yet, because I have been busy with important things like how to get certain things patched and what not. And making the new patches robust and the ebuilds nice.
To use the updates, overwrite the files in your overlay, then do:
emerge =x11-libs/qt-3.3.8-r4 =x11-libs/qt-4.3.3
I found that I need to restart my machine for the new Qt features to really take hold. You do not need to recompile kdelibs if you are recompiling these from a previous install of qt-copy. You only need to re-compile kdelibs if you have any weirdness or if this is your first time with qt-copy.
How do I get it and how I install it?
1) Download
2) Make an overlay and extract the archive in that overlay.
3) Make sure you have the qt-copy useflag set (if you used pertty/xeffects chances are you do)
4) Install the QT version you need.
TODO:
Figure out the many ebuilds that make up Qt 4.4. I need to see what patch goes with what ebuild since it is all broken up.
Thank you for trying these out. If you have any questions or comments, I would love to hear from you. Just say thanks if you want.  I hope you learned something with my history lesson. I do tend to talk a lot.  And over use smilies.
EDIT: 20080115: updated ebuilds. The new link is in the how to install section.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Sat Jan 19, 2008 8:14 pm; edited 8 times in total |
|
| Back to top |
|
 |
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Sun Jan 06, 2008 11:11 pm Post subject: |
|
|
Note to former XEfeects users:
You will need to modify the kdelibs to remove the check for the pertty use flag in Qt. Just read the ebuild until you see the block of text that has Qt and pertty in it and that should be it. You can just change pertty to qt-copy if you want to leave that in there. It might be good to have to remind yourself that you need to have qt-copy enabled to have pertty enabled on kdelibs.
Also, after installing qt-3.3.8, you will need to recompile kdelibs-3*, whatever version you are using. Apparently I have some newer patches than the last version of qt-copy in XEffects ... well my qt-copy is from the 20080109 or there abouts, so there is a slight change. If you don't recompile, then you will not be able to log back in.
I already had KDE 4.0.0 (grabbed it from the 4.0.0 tag in the svn) so I do not know if KDE4 stuff needs to be recompiled against Qt Copy. I think it does because they have a patch identifying it as Qt Copy, so KDE4 might actually take advantage of some of the specific changes. So, I will say, recompile kdelibs-4* as well just to be on the safe side. It can't hurt anything, and you get the added advantage of some special tweaks, apparently.
I will keep you posted on any other going ons.
Later all.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:54 am; edited 2 times in total |
|
| Back to top |
|
|
loftwyr
l33t
Joined: 29 Dec 2004
Posts: 970
Location: 43°38'23.62"N 79°27'8.60"W
|
| Posted: Mon Jan 07, 2008 12:47 am Post subject: |
|
|
Are you going to set this up so we can use layman to install it or will you wait for nesl's desktop-effects overlay to come out?
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Mon Jan 07, 2008 3:06 am Post subject: |
|
|
| loftwyr wrote: | | Are you going to set this up so we can use layman to install it or will you wait for nesl's desktop-effects overlay to come out? |
That's a good question. I think I might wait to see what desktop-effects is all about first. They can use the modifications I made in their overlay if they wish. I could tell them how I did it. Though, there are only three ebuilds in this overlay and KDE people don't update Qt Copy that often, so I didn't think it would be too much of a hassle to mainly extract this once-in-a-while. I date the tarballs so it's easy to tell when an update happens. These can be places in a non-layman controlled overlay, like I have a misc overlay where various things go when I modify a Gentoo ebuild.
So, we will see what happens. I hope I answered your question.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:55 am; edited 1 time in total |
|
| Back to top |
|
|
Ingmarv
Retired Dev
Joined: 27 Feb 2007
Posts: 188
Location: Belgium
|
| Posted: Mon Jan 07, 2008 1:09 pm Post subject: |
|
|
| loftwyr wrote: | | Are you going to set this up so we can use layman to install it or will you wait for nesl's desktop-effects overlay to come out? |
It's not nesl's, it's jmbsvicetto's, Philantrop's & mine.
And no, we're not planning on maintaining Qt and KDE ebuilds there. We will focus on compiz & the likes.
I hope that clears up things. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Mon Jan 07, 2008 3:29 pm Post subject: |
|
|
| Ingmarv wrote: | It's not nesl's, it's jmbsvicetto's, Philantrop's & mine.
And no, we're not planning on maintaining Qt and KDE ebuilds there. We will focus on compiz & the likes.
I hope that clears up things. |
This clears a lot up. I guess it's time to dust off the old pertty patches. Though, they will not be called pertty patches or KIP, they will just be patches until KDE4 is mainstream because KDE4 has a lot of what the pertty patches did, so there is kinda no point to them anymore. I also guess that this means I need some better way to distribute Qt Copy (I am finally saying Qt right, before I used QT XD ooops.). I will look into these things. Layman has support for tarballs, so that could be my first step I guess. Or use my SF account. They have source control.
Hmmm.... maybe I should add this to the to do: Figure out a way to make the MacOS only patches compatible with portage on Mac? Though, there are only two in the entire set of patches I have, so maybe it's not worth it.
What to do? What to do? *thinks*
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:55 am; edited 1 time in total |
|
| Back to top |
|
|
Philantrop
Retired Dev
Joined: 21 Dec 2004
Posts: 1130
Location: Germany
|
| Posted: Mon Jan 07, 2008 11:42 pm Post subject: |
|
|
Dear Stiff-in-Death,
| StifflerStealth wrote: | | I guess it's time to dust off the old pertty patches. |
Just for clarity: Anyone using KDE ebuilds from an overlay will get no support whatsoever if stuff from official KDE ebuilds breaks. xeffects was horrible with respect to that and I really don't want to see that repeating itself.
Regards, Philantrop |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Tue Jan 08, 2008 12:26 am Post subject: |
|
|
| Philantrop wrote: | Just for clarity: Anyone using KDE ebuilds from an overlay will get no support whatsoever if stuff from official KDE ebuilds breaks. xeffects was horrible with respect to that and I really don't want to see that repeating itself.
Regards, Philantrop |
Yes, and I am partially to blame for the condition of those old ebuilds. I should have made them better, but I didn't. With the new Qt ebuilds I made in this thread, the user can disable the qt-copy flag and get back the precise version of Qt that the Gentoo devs put together. Thus an improvement in that respect. Before, that never happened: a lot of times a patch inserted by a Gentoo dev was removed from the ebuild, which was the wrong thing to do. I plan to do the same with KDE ebuilds, although, I am almost tempted to forget it since KDE 4.0.0 is coming and it does exactly what the KDE3.x patches do.
Also, I also mention in this thread that all support for patches I release should be in this thread.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:55 am; edited 1 time in total |
|
| Back to top |
|
|
no4b
Bodhisattva
Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland
|
| Posted: Tue Jan 08, 2008 5:50 pm Post subject: |
|
|
qt-3.3.8-r4 + qt-copy works, thanks.
_________________
GTK2/GNOME - The weakest link! |
|
| Back to top |
|
|
creidiki
Apprentice
Joined: 23 Mar 2007
Posts: 283
Location: Varese (Italy)
|
| Posted: Tue Jan 08, 2008 9:01 pm Post subject: |
|
|
the old xeffects ebuilds currently live in the arcon overlay, maybe you can just put them there?
_________________
'((eINIT) (soor overlay)) |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Tue Jan 08, 2008 9:17 pm Post subject: |
|
|
| creidiki wrote: | | the old xeffects ebuilds currently live in the arcon overlay, maybe you can just put them there? |
I read in that overlay that the owner of the overlay may not keep up the current versions of the Qt ebuilds that are already in there. I don't mind hosting the tarball of the ebuilds, it's a really quick download and extract. That way you don't get a lot of ebuilds you don't want in some of those overlays. Qt Copy is not updated very often, so it's not really difficult to maintain it.
Cheers.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:55 am; edited 1 time in total |
|
| Back to top |
|
|
Thargor
Apprentice
Joined: 23 Dec 2005
Posts: 239
Location: Bamberg/Germany
|
| Posted: Wed Jan 09, 2008 2:17 pm Post subject: |
|
|
Maybe you could set up a repo (cvs, svn, git, whatever, i don't care)
That would be a lot easier to use, at least if you are maybe going to do the same for Qt-4.4
_________________
Ideas are bulletproof |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Wed Jan 09, 2008 7:14 pm Post subject: |
|
|
| Thargor wrote: | Maybe you could set up a repo (cvs, svn, git, whatever, i don't care)
That would be a lot easier to use, at least if you are maybe going to do the same for Qt-4.4 |
Yeah. I am working on something better. I know layman has tarball support, so I will figure out how to do that first. That will be simpler. I am also thinking of adding in some ewarn output to remind the user to not submit bugs to bugs.g.o when they have qt-copy enabled.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:55 am; edited 1 time in total |
|
| Back to top |
|
|
Non_E
Apprentice
Joined: 17 Jan 2006
Posts: 160
Location: Czech Republic
|
| Posted: Wed Jan 09, 2008 7:33 pm Post subject: |
|
|
Hello,
it is nice to see perrty is back. Have you encountered any issues with it so far? I remember some python issues when it refused to load pyqt. I'd like to know in advance - remerging kde is not a short-term task, at least on my machine
Thanks, I look forward to perrty
_________________
Only Sith deals in absolutes. |
|
| Back to top |
|
|
Wittgenstein
n00b
Joined: 27 Sep 2007
Posts: 4
|
| Posted: Wed Jan 09, 2008 7:34 pm Post subject: |
|
|
Are there any compelling reasons why your Qt4 ebuilds/eclasses still suppress the RPATH/RUNPATH header entry in Qt shared libraries? The ebuilds refer to bug #75181 related to Qt 3.3.*. Have you ever tried to verify this bug with later revisions? I have build qt-copy (essentially Qt 4.3.3 with some patches) form KDE svn trunk myself, and get the correct behavior
| Code: |
readelf -d /usr/qt4/lib/libQtCore.so | grep "PATH"
0x000000000000000f (RPATH) Library rpath: [/usr/qt4/lib]i
0x000000000000001d (RUNPATH) Library runpath: [/usr/qt4/lib]
|
for each lib in /usr/qt4/lib. (my build directory is /home/roland/src/kde/qt-copy).
Wittgenstein |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Wed Jan 09, 2008 8:06 pm Post subject: |
|
|
| Wittgenstein wrote: | Are there any compelling reasons why your Qt4 ebuilds/eclasses still suppress the RPATH/RUNPATH header entry in Qt shared libraries? The ebuilds refer to bug #75181 related to Qt 3.3.*. Have you ever tried to verify this bug with later revisions? I have build qt-copy (essentially Qt 4.3.3 with some patches) form KDE svn trunk myself, and get the correct behavior
| Code: |
readelf -d /usr/qt4/lib/libQtCore.so | grep "PATH"
0x000000000000000f (RPATH) Library rpath: [/usr/qt4/lib]i
0x000000000000001d (RUNPATH) Library runpath: [/usr/qt4/lib]
|
for each lib in /usr/qt4/lib. (my build directory is /home/roland/src/kde/qt-copy).
Wittgenstein |
I do not include an eclass in these ebuilds. They use the original from Gentoo. Also, the ebuilds are the original from Gentoo with the only difference of having the Qt Copy patches. If anything is suppressing the RPATH/RUNPATH then it is either one of the Qt Copy patches (not likely since you have the same) or it is something that Gentoo is doing and you need to ask them why they do that in the Qt ebuilds. Also, Gentoo installs that lib to: /usr/lib/qt4/libQtCore.so. You directories are switched. Not related to the issue, but good to know.
Cheers.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:56 am; edited 1 time in total |
|
| Back to top |
|
|
Wittgenstein
n00b
Joined: 27 Sep 2007
Posts: 4
|
| Posted: Thu Jan 10, 2008 4:33 pm Post subject: |
|
|
| Sorry, I supposed you were responsible for the ebuilds. Meanwhile I have added my questions as comment to the old bug report. Let's wait and see. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Thu Jan 10, 2008 5:23 pm Post subject: |
|
|
| Wittgenstein wrote: | | Sorry, I supposed you were responsible for the ebuilds. Meanwhile I have added my questions as comment to the old bug report. Let's wait and see. |
No problem. I think they can get away with excluding those paths in that file because the ebuilds put a file in /etc/env.d/ The ones I have in there related to QT are: 44qt4, 45qt3, and 50qtdir3. They contain all the paths to the QT stuff. If you compiled from the KDE SVN, they will not have that file, thus those paths might need to be set?
Cheers.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:56 am; edited 1 time in total |
|
| Back to top |
|
|
Mr. Tao
Tux's lil' helper
Joined: 20 Jul 2007
Posts: 147
|
| Posted: Fri Jan 11, 2008 5:41 pm Post subject: compile problems |
|
|
I'm trying to rebuild kde. I have qt-4.3.3 and qt-3.3.8-r4 compiled with qt-copy flag and I removed pertty flag check from ebuilds as described. But when I got to libkonq package, I received following error: | emerge -av1 libkonq wrote: | In file included from libkonq_la.all_cc.cc:6:
konq_iconviewwidget.cc: In member function 'virtual void KonqIconViewWidget::visualActivate(QIconViewItem*)':
konq_iconviewwidget.cc:1851: error: no matching function for call to 'KIconEffect::visualActivate(QWidget*, QRect&, QPixmap*)'
/usr/kde/3.5/include/kiconeffect.h:154: note: candidates are: static void KIconEffect::visualActivate(QWidget*, QRect) |
If I skip this package, same problem arises with different kde packages. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Fri Jan 11, 2008 6:43 pm Post subject: |
|
|
Mr. Tao: Did you make sure you compiled Qt 3.3.8-r4 from my overlay? To check, do a: emerge -pv =x11-libs/qt-3* and look to see if you see pertty in the use flag list, if you do, then you have the wrong Qt.
If you are using ccache, try this:
ccache -C (Note: That is a capital "C")
emerge =x11-libs/qt-3* =kde-base/kdelibs-3* =kde-base/libkonq-3*
I added the kde-base part to make this compatible with the upcoming release of kde4.
at any rate, kdelibs need to be compiled before libkonq. I just tried on my machine and I do not get this error. I have the old Xeffects ebuilds in my overlay as well. Did you compile in that order?
If the above does not work, then please post back.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:56 am; edited 1 time in total |
|
| Back to top |
|
|
Mr. Tao
Tux's lil' helper
Joined: 20 Jul 2007
Posts: 147
|
| Posted: Sat Jan 12, 2008 4:27 pm Post subject: |
|
|
| StifflerStealth: I have qt-copy flag in x11-libs/qt-3.3.8-r4 and no pertty. I cleaned ccache and then I did emerge -avt1 =x11-libs/qt-3* =kde-base/kdelibs-3* =kde-base/libkonq-3*. Unfortunatelly I got the same error I posted before. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Sat Jan 12, 2008 5:30 pm Post subject: |
|
|
In the output of your emerge line, what version of kdelibs do you see? You are emerge-ing libkonq, which I believe is from the XEffects overlay. There are newer versions of kdelibs in portage, so if you do not see kdelibs-3.5.8-r1 as the version that _is_ being installed, then you have a newer non-xeffects version of kdelibs. The ebuilds are bad about checking for other ebuilds with xeffects. I am slowly working on newer ebuilds, but I have limited time. If by chance your kdelibs is greater than -3.5.8-r1, then you need to do the following command:
echo >kde-base/kdelibs-3.5.8-r1 >> /etc/portage/package.mask
Also, you need to look at the revisions of all the xeffects kde ebuilds and if you have newer versions installed, then you need to mask those as well.
*hopes this is the solution this time*
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:56 am; edited 1 time in total |
|
| Back to top |
|
|
Mr. Tao
Tux's lil' helper
Joined: 20 Jul 2007
Posts: 147
|
| Posted: Sat Jan 12, 2008 6:41 pm Post subject: |
|
|
| Quote: | zoo ~ # emerge -p kdelibs
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] kde-base/kdelibs-3.5.8-r3 [3.5.8-r2] |
I'll try to emerge =kdelibs-3.5.8-r1. I have libkonq-3.5.7 from xeffects overlay installed. |
|
| Back to top |
|
|
StifflerStealth
Retired Dev
Joined: 03 Jul 2002
Posts: 968
|
| Posted: Sat Jan 12, 2008 7:42 pm Post subject: |
|
|
Okay .... 3.5.7 of libkonq with a 3.5.8 version of kdelibs.
Do you have the pertty flag activated on the kdelibs and libkonq ebuilds?
The dependencies of libkonq with pertty is kdelibs with pertty. Thus you need to make sure that you have the pertty flag active for libkonq and kdelibs. Also, are you trying to reinstall libkonq 3.5.7? If you don't want to use pertty patches at all, then disable pertty for all ebuilds. Then you need to make sure that you have the correct depends installed. Unless you are just now trying to update from kde 3.5.7. If you want pertty then, then you need to look at what revision the xeffects ebuilds have.
Since you have kdelibs-3.5.8-r2 without pertty and libkonq with *assuming* pertty, this is what I mean by saying that the ebuilds from xeffects are in bad shape. This shouldn't be allowed.
_________________
Nothing to read in this sig. Move along.
Last edited by StifflerStealth on Mon Jan 14, 2008 3:56 am; edited 1 time in total |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Sun Jan 13, 2008 8:13 pm Post subject: |
|
|
when will the qt-4.4_rc1 ebuild be available? since i use gcc43, the previous versions do not compile for me 
dodo
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
