[PyKDE] 10.0 official rpms for PyKDE
joe at suse.de
Wed May 26 18:57:01 BST 2004
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
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
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
More information about the PyQt