> Same with the "unofficial" SUSE RPMs. > My target is to build a set of upgraded "Qt/KDE Python tools" including > Python 2.3.4, SIP 4.0, the latest stable PyQt, PyKDE 3.11, and Eric 3.4.2.
> The problem is that during the last couple of weeks there was not a > single day when all of the parts of the whole were stable at the same > time ;-) I believe you'll find that mentioned in the Book of Revelations as sign of the end of the world. :) > It would be great if we could get the "Python tools" in sync with the > next major KDE release (3.3), i.e. at the time KDE is released the > upgreaded Python bindings are available, too ... KDE 3.2.3 is due in the next few weeks (last time I looked at the KDE release schedule), and the next PyKDE release should be ready very shortly after that. Phil has just released sip 3.10.2 (which the next PyKDE release will require) and hopefully the last sip4 rc (which PyKDE should work with), so sip 4.0 should be fairly close. Phil is also planning a PyQt update shortly. So everything should be in sync then. From what I've looked at, KDE 3.3 won't change a lot in kdelibs (which is all PyKDE cares about), and I'm planning on tracking the betas and rc releases. If the last kdelibs 3.3rc is binary compatible with the final release, I could have PyKDE complete *before* the final. But then in theory, 3.3 is supposed to be binary compatible with 3.2, I believe. The problem in doing that is that the final rpms from SuSE, Mankdrake and whatever RH/Fedora is doing now are never compatible with "official" KDE source code (I get the source either from kde.org or uk.kde.org) - eg KFileShare::setShared on SuSE 3.1.x later rpm releases, similar stuff on Mdk or RH, QXEmbed with some distros, etc. It only takes one modified or deleted method to make PyKDE essentially unusable - PyKDE binds nearly every method in the kdelibs modules it supports, which most apps don't do. That being the case, I'd be shooting myself in the foot by doing a release ahead of the official KDE 3.3 rpms and not testing against those. Usually, I only build against the latest KDE on SuSE, but test earlier versions against Mdk and RH. I have enough problems when I do test (eg, the current problems with kdeui not finding kdefx on Mdk 10.0, which doesn't happen on Mdk 9.x, any SuSE after 8.1 or RH9.x). With PyKDE now up-to-date with sip and PyQt and vice versa (which wasn't the case earlier in the year), it shouldn't take much more than a week to have a KDE3.3 version available. Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde