Hi!
Jim Bublitz wrote:
I wouldn't mind doing this for any distribution. I can't promise to test against every beta/rc since both the download time and build time/build problems can be a lot of extra work. I can try to keep up with the rc releases and submit packages to you.
We just need the most current PyKDE source tarballs in time during the beta phase. Building is mostly automated, and as long as the tarballs don't differ much it should be no problem for us to update the RPMs for every beta (or at least every second or so).
If there are any automated tests we could run them as part of our QA efforts. And of course we can provide betas to you ...
The major issue is that the code base the distro uses has to match the code base PyKDE is written against in that every class/method has to continue to exist and every method has to have the same argument list (as well as the obvious - having a compatible sip/PyQt version). If that doesn't happen, one or more PyKDE modules won't be loadable under Python. So all that's necessary is to run the importtest.py script that comes with PyKDE. All that does is try to import each module. New methods shouldn't cause a problem - PyKDE just won't know about them. Repairing any problems is usually pretty trivial - comment out missing stuff, or modify an argument list.
OK. That's what I expected.
You could probably run importtest.py as part of the rpm install if you wanted to.
Yes, we can even do that in the build system after compiling and before packaging the binary RPMs ...
As far as betas, I assume that involves downloading a few CDs worth of data. I'm on a satellite link and it isn't the most reliable bandwidth for downloads that large. However, Hans-Peter Jansen is very familiar with PyKDE build procedures and problems, and becoming familiar quickly with PyKDE internals, so he might be a good candidate to do that kind of testing - if he's interested. I'd support him as much as needed, of course.
Same with us.
I hope my earlier post wasn't taken as being angry or flaming
No, not at all ;-)
- I'm very interested in working with SuSE or other distributors,> but the main concern
is getting something usable and reliable to PyKDE users (which I haven't always succeeded at).
That's my main concern, too. The reason why I'm trying to get things in sync with our distro is that only if PyKDE comes with the distro people who don't know how to compile stuff on their own will be able to run Python-based KDE applications. And only if PyKDE becomes an integral part of the major Linux distros will we see a significant number of developers switch to PyKDE. A lot of people just won't use a tool if they have to install libraries from a third party first ...
Just let me know how you want to handle this and we'll see if it can be worked out.
Sounds great. My schedule for PyKDE/PyQt/SIP/eric3 on SUSE is trying to build "unofficial" SUSE LINUX 9.1 rpms for KDE3.2.3 as soon as this is possible. PyKDE is the only part that is missing on 9.1, but the other parts can need an upgrade, too.
For 9.2 (which should more or less match with KDE 3.3) we will then get the latest stuff released as part of the distro if everything goes well.
There's one thing I'll have to check with Stefan Kulow (the KDE release manager): If PyKDE becomes part of the KDE release itself we'll have to change the processes a bit. The guys who do the Java bindings are doing this already.
Cheers
Joe
-- Joachim Werner SUSE RD-TPM
_______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
