[PyKDE] PyKDE - almost

[Bruce Sass]

On Tue, 5 Aug 2003, Jim Bublitz wrote:
> On Tuesday August 5 2003 20:03, Bruce Sass wrote:
> > <sigh>
> > KDE-3.1.3 installs and the next day you announce that PyKDE
> > for 3.1.1 and 3.1.2 is on the horizon.
>
> 3.1.1 should work with the current release (but only at sip 3.5).
>
> > On Tue, 5 Aug 2003, Jim Bublitz wrote:
> > <...>
>
> > > Argh! Hadn't checked kde.org in the last week or so. I'll
> > > make this the second release - hopefully a few days after
> > > the first one. It only takes about 30 minutes to upgrade (at
> > > least for point releases). The time consuming part is
> > > d/l'ing and installing the new KDE release (along with
> > > another Linux install). However by dropping the KDE2 stuff,
> > > I have lots of free partitions at the moment.
>
> > I may as well be blunt about it...
>
> > You should stop actively working with out-of-date software.
>
> > I like the idea of being able to get PyKDE working no matter
> > what version of Py or KDE one has, but it just doesn't seem to
> > be working.
>
> My philosophy is that upgrades shouldn't be forced, so I like to
> maintain backward compatibility as far as practical. Dropping
> KDE2 was pretty arbitrary, but I don't expect many people (or
> any) still depend on it. On the other hand, I've only been
> running KDE3 (in production) for about 6 months.  Probably
> similar to the reasoning Debian applies to 'stable'.

Debian stable is at KDE2, 3.1.3 is available unofficially... does
"dropping KDE2" mean Debian-stable users will need to upgrade if they
want to run PyKDE, or will you help if someone wants to backport. The
former is `dropped' and the latter `not actively working on'.

I was not suggesting that anyone who wants to use PyKDE should be
prepared to upgrade their system, just that the bulk of the
backporting work should be done by someone other than you.

> > Why not stick with the most recent releases and CVS snapshots
> > of sip, Python and KDE -- leave the work of getting a PyKDE
> > built for an old release of Python with an old release of KDE
> > and who knows which version of sip to those who actually are
> > going to use it.  Give'm a hand and apply patches to PyKDE
> > which don't break things, but don't spend time trying to build
> > using (say) sip-3.4, Py-2.1 and KDE-3.0.4 when 3.7, 2.3 and
> > 3.1.3 are the current releases.
>
> I haven't maintained PyKDE against earlier versions of sip -
> that's pretty difficult to do, and a lot of what Phil puts in
> sip upgrades (moreso in the past than now) is for the benefit of
> PyKDE in the first place. Phil does a good enough job (along
> with the Python guys) that tracking Python versions has never
> been a problem for me (and I don't think much problem for Phil).
> But again, I'm still back at KDE 3.1.0 on my work machines and
> will be for a while probably, and other people are probably
> further back still.

That is what I'm getting at; there is a sliding window of supported
subsystems, but it seems to be centered on the past.  I do realize
that sip has evolved because of PyKDE, and consequently it will be
impossible to build PyKDE with some versions of sip.


> > Have you considered using chroot setups instead of fresh Linux
<...>
> It's easier to multi-boot than to use chroot

just a thought, please stick with whatever works best for you

> because I test against multiple distributions (or would if I could
> get Mandrake to work and not just RH and SuSE) and multiple versions
> of distributions. gcc, Python, etc. The problems that arise
> otherwise are similar to what I wasted an hour on tonight - I
> test-built against KDE 3.0.3 on SuSE 7.3 and had all kinds of
> problems with one module (unresolved symbols).
<...>

<sigh>
That is exactly the kind of thing I think you should leave to
others... splitting that hour between keeping track of the local fire
situation and working on current PyKDE issues would have probably
served both you and PyKDE better.


> > Have you considered changing to a distro which does a better
> > job of keeping you up-to-date...  I know Debian-unstable is
> > good in this respect[1], Mandrake's "Cooker" would probably
> > also do (sounds like it is more unstable than Debian-unstable,
> > which I hear isn't much worse than other's releases[2]), I
> > don't know what RH and SuSE offer the developer).
>
> Mandrake 9.0 had problems in its Qt setup I didn't want to spend
> time working through. I installed Mandrake 9.1 last night and
> couldn't get it to network - might just need some 'route add'
> stuff, but I didn't feel like going through that at the moment
> either. So I'm not real big on Mandrake at the moment. The
> 'drake' stuff to do networking setup was badly broken too, but
> that might be Cheapbytes fault.

I don't think you should be "big on" any specific distro, not sure
how practical that would be though.

> Debian, on the other hand (hi Ricardo!) actually provides support
> and packaging for *current* PyQt and PyKDE versions, so I feel
> like those problems are covered.  I need to build and test
> against the distributions that don't provide support.

Don't the other distros have developers.

> The bottom line is that PyKDE should run on nearly anything, so
> whether I develop somewhere else or not, I still need to be able
> to handle SuSE, RH and other problems, and I'd like to get them
> out of the way pre-release. Personally I find SuSE a lot easier
> to install and configure, but I'm used to it too.

I agree, except for the part where you need to be able to handle RH
and SuSE.


> > Consider this before you do "another Linux install"...
> > Debian-unstable is built by developers for the purpose of
> > developing software[3], it is not a snapshot of the next
> > release or targeted towards any particular use or user (i.e.,
> > desktop, server, newbie, enterprise, etc.) as you will likely
> > get by installing a commercial distro's release or development
> > version.
>
> > Sorry for degenerating into a Debian advert.  I just can't
> > help thinking that part of why I haven't been able to try
> > PyKDE is because of the time you have been spending tracking
> > upstream releases and installing Linux -- when my distro does
> > all the infrastructure stuff for me and I haven't needed to do
> > an install for years.
>
> I don't mind the Debian advert at all - Debian just doesn't solve
> *my* problems. I still have to fix PyKDE when the KDE h files
> are out of sync with the SuSE KDE libs, and considering what's
> involved in locating/fixing those problems, it's much better to
> do it on SuSE in the first place. (Not to be too negative about
> SuSE - I prefer it over anything else I've tried)

I guess that is where we differ; I don't think problems like that
should be *yours*, they should be (in this case) SuSE's.

> I'm only concerned about shaving days or hours off development
> time right now because I want to get this release out ASAP. The
> overriding problem is not having had any time at all to spend on
> it the last few months. I've just had a rash of problems from
> dogs getting snake bit to other peoples dumb software problems
> (switching from Linux to Windows - sheesh!) just about costing
> me half of my business' sales, and everything imaginable in
> between. Short of 'apt-get anti-venin' or 'apt-get LART'
> working, I don't think the distribution I use makes that much
> difference in the long run.

Ya, real life does intrude on volunteer efforts from time to time, not
much can be done about that unless you can find a way to turn PyKDE
into bread (so it becomes a matter of "real life").  However, I think
the distro you use does impact in the long run if you need to spend
time finding and installing newer versions of stuff.

> Speaking of interruptions, we had a lightning storm go through
> tonight, and there are a couple of fires up valley from us. The
> Forest Service already has crews on them. It's cool and wet now,
> but it'll be tomorrow afternoon before we know for sure they're
> under control. Meaning tomorrow morning I have to hook up the
> fire pump (which should have been done already) and a few other
> miscellaneous things in case we need to evacuate. Doesn't seem
> likely at the moment though.

Forest fires have always made the news here in Canada, even those in
the US... I wonder how much impact the US Immigration decision to
require Canadian smoke jumpers and hotshot crews to pass through
customs instead of going directly to the fires has had.


> > One other part is a 28.8kpbs connection and a P133, otherwise
> > I'd be downloading and building instead of ranting at you.
>
> That's about a 4-5 hour build time for PyKDE (or maybe 10-12 if
> you don't have a lot of memory)?

Hmmm, I could probably handle 4-5 hours, 10-12 would tax my attention
span too much though (it would end up being a day or two because I'd
get sidetracked doing something with a shorter cycle).  What kind of
time do you think 96M RAM would get me?  The 28.8 modem will likely be
replaced with broadband within the next month or so... is there
anything a marginally skilled person such as myself will be able to
contribute to the effort (IOW, what skill set should a potential
contributor to the PyKDE effort have)?


> > [2] It is rare to see someone struggling with a Debian
> > (unstable or stable) problem on the local LUGs mailing list;
> > RH and Mdk users seem to be always trying to find something or
> > get "this" to work with "that" (especially the RH users, and I
> > don't know what they are going to do now that they can't wait
> > for the *.1 or *.2 minor release before upgrading :-).
>
> RH, Mdk and SuSE are in the stores, so they probably get
> disproportionately more newbies. Most of the Debian (or gentoo,
> etc) users I know started out on something else.  I've come to
> prefer the "dumbed-down" installs --- 6-7 years ago I wouldn't
> have minded spending a day getting PPP to work; everything's so
> easy now, I won't take the time to manually set up networking
> when Mdk won't do it for me.

I've taken the newbie and user base size issues into account.  By
"struggling" I mean problems whose solutions are not immediately
obvious and can't be configured away... build it yourself from source
because the 3rd party packages use old libs or a weird configuration
kinda stuff, not the pick Mandrake's high security install option and
wonder why some of the networking doesn't work sorta issues (maybe
that is what you are running up against with Mdk).


- Bruce