Remember: Documentation is top priority
I always thought that writting documentation is much more difficult than coding. This is because, writting documenation and guides, is kinda boring(?), requires a lot of our free time and it is not as fun as coding. All of these arguments IMHO are true but is documentation really needed?
During my six month Gentoo journey I faced a common problem: “I want to write a python/gnome/qt ebuild. How on earth am I suppose to do it??”
Looking through Gentoo docs I ‘ve found some guides about writting games and python ebuilds. Maybe there are more, I haven’t checked. Those guides are quite handy for anybody who wants to write a quick ebuild without making serious mistakes.
Eclasses usage is another tricky thing. Based on my experiense, I believe that the most difficult part is to understand how they work and when they should be used on an ebuild. E.g., a Qt4 ebuild doesn’t always require to inherit qt4 eclass because it might wants cmake functions to build and install. In this case, despite the fact that it is a pure Qt4 package, you need to inherit the cmake-utils eclass. That was a simple example but I believe you got the point :)
This blog post is a kind request to all fellow developers, to make some time and write proper ebuild guides ( and keep them updated based according to eclasses’ latest changes ) for the sake of developers and users. People tend to believe that ebuild writting is quite hard because of all the e-* functions ( wrappers ) and ebuild phases. Prove them wrong :)
ps: A Qt4 ebuild guide, can be found here
New sip/PyQt{,4}/qscintilla{,python} on portage
I haven’t written anything for a while due to real life obligations. I am writing my Thesis, plus I am in the middle of my (final?) exam period.
Anyway, I just committed the following packages on portage tree:
- dev-python/sip-4.8
- dev-python/PyQt4-4.5
- dev-python/PyQt-3.18
- dev-python/qscintilla-python-2.4
- x11-libs/qscintilla-2.4
We have been testing them on qting-edge overlay for a while and since we didn’t encounter any breakages, we decided to push them on tree. I ‘d like to thank Ben de Groot(yngwin) and Davide Pesavento(Pesa) for cleaning up and testing the ebuilds during this period.
Even though we tested as many PyQt applications as possible, to verify that nothing breaks with the new packages, there might be some breakages. If you find any, please let us know by filling a bug :)
Enjoy your shiny new packages ;-)
Updated: 11-06-2009
New pykde4 committed which solves compatibility issues with PyQt4-4.5 ;)
Crazy about Qt? Time to prove it :)
Many of you might have already seen my e-mail on gentoo-dev ml. For those who haven’t , Qt herd is about to face lack of manpower after July. We already have two upcoming developers but we could use some more as well :). So, if you are willing to help us keep Qt in a high QA level you could do it using the following two ways:
1) Qting-edge overlay is open to new contributors who are willing to see their favorite Qt4 applications reach an official gentoo overlay. Of course you will need to prove that you have some ebuild skills. Not much, since our magic eclasses do all the dirty stuff. We are trying to keep the quality in high levels, so we might need to review your commits before you do them ( at least at the beggining ).
2) If you always wanted to become a Gentoo Qt developer , now it’s the chance. We could mentor you as well as helping you with your ebuild quizes.
So, feel free to contact us via qt[at]gentoo[dot]org if you are willing to contribute :)
Qt-4.5.0 on Gentoo portage tree
Finally Qt-4.5.0 is out. Ben pushed it yesterday on portage tree. Qt-creator-1.0.0 version is out and on tree as well :) .
For those who havent yet moved to qt-4.5 series, I strongly recommend to read my previous blog post about Qt upgrade.
However, I want to give you some extra hints.
Raster use flag: So far this flag seems to do more damage than I originally thought . So if you have qt-gui compiled with this flag and you experience weird behavior on Qt/Kde4 apps , the first thing you have to do, before feeling a bug report, is to disable raster use flag.
Broken KDE4 apps: About a month ago ,we decided to bring qt-4.5.0_rc1 on tree . This decision annoyed some of our users and blame us for not masking qt-4.5.0_rc1. On the other hand, having more and more users using qt-4.5.0_rc1 , lead to find and fix many bugs concerning kde4 apps + Qt-4.5. We ( as Gentoo users+devs ) reported many of them on kde bugzilla and kde devs fixed them quite quickly. Some of them are still unresolved but kde upstream is aware of them so they should fix them on trunk soon and we will back port the patches on current kde4 packages as well.
So , I would like to thank our users for doing a GREAT work on our bugzilla by filling many bugs, providing patches, reporting upstream bugs and giving us a lot of feedback about kde4+Qt-4.5 cooperation.
Keep up the good work fellows and we will do our best as well.
So , happy emerging your shiny new Qt-4.5 packages :)
Qt-4.5.0_rc1 hit the tree. Should you upgrade?
..or not? Let me do a quick summary first. Qt-4.5.0_rc1 has been on qting-edge[1] overlay for up to two weeks now. We fixed as many bugs and building problems as possible. This version of Qt seems to be way too better than _beta1. From my part I would say yes upgrade. In case you are a kde4 user you might encounter several bugs. I ll come to this a bit later. So I d like to give you some directions on serveral problems that hit users the first hours of qt-4.5.0_rc1 release.
How to ugrade? I have tones of blockages!
In case portage complains about a hell of blockages the solution is quite simple. Obviously you were using the qt metapackage ( x11-libs/qt:4 ). If this is the case, you need to un emerge it:
emerge -C x11-libs/qt:4
Then you need to edit /var/lib/portage/world. Find x11-libs/qt entry and modify it like this:
x11-libs/qt:3
Now you are done. Run emerge -uDNav world and everything should be fine. If you still have questions about this , please drop by Gentoo forums[2]. We have a dedicated thread for this situation[3].
Ok I upgraded. Now kde4 looks ugly/crashing/etc
A known issue is a kdm crash. You wont have it if you are using the latest kdm in the tree. If you dont, please upgrade.
As the ewarn message suggest, you should re-build PyQt4, qscintilla, kdelibs. Our Gentoo KDE Devs suggest to rebuild libplasma and plasma-workspace. The fact that most of our users dont have such crashes make me think that you should rebuild everything that fails. But thats quite abstract.
If you still have issues after rebuilding please follow the below steps to fill a bug:
1) Open a bug on kde bugzilla[4]
2) Open a bug on our bugzilla[5]and assign it to kde_AT_gentoo.org
3) Paste the link from upstream bug on the bug you opened on Gentoo bugzilla
4) We ll take it from there. Just be around in case we need you to provide more info to us
This might sound too much but it will really help us track all the problems and poke upstream about that. So it is just a 5′ work that might help hundreds of other users
You can always not open a bug on our bugzilla and monitor it yourself but I would prefer to know all the problems and the possible patches that fix them in order to apply them on portage.
Conclusion:
People keep complaining that we should remove Qt-4.5 or mask it from tree. I will provide you two links[6][7] why I think we should have it or what problems you might encounter . After all is ~arch so it is normal to expect some mulfunctions for those who use KDE4. But please remember that not everybody is using KDE4. There are other people with xfce,fluxbox and other DE that want a shiny new Qt for their Qt4 applications. Should we dissapoint them in favor of KDE4? I dont think so
Links:
[1] http://github.com/gentoo-qt/qting-edge/tree/master
[3] http://forums.gentoo.org/viewtopic-t-736457.html
[6] http://labs.trolltech.com/blogs/2009/02/10/why-kde-42-should-use-qt-45/
[7] http://labs.trolltech.com/blogs/2008/12/04/how-kde-4-is-blocking-qt-45/










