I've just pushed a number of related commits to the kde-sunset git. The
idea is to incorporate all changes committed to the 3.5 branch in the
upstream svn repository. This gives us some security fixes, some
portability fixes, some translations, and in general ensures that work
done by KDE 3.5 devs won't go to waste.
I've ensured that all these patches do apply, and I've successfully
compiled most of the packages as well. I'm actively using only a small
number of these apps myself, so I can'd give you any comment on runtime
behaviour. I've had a cursory glance at most of the patches, but haven't
looked for interaction with other Gentoo patches, unless the patches
failed to apply in sequence. So it might well be that KDE svn fixes some
issue and Gentoo fixes the same issue in a different place in the code,
causing a double fix which might be wasting resources in the best case
and actually breaking stuff in the worst case. Nevertheless, I deem such
changes colliding at run-time but not at patch-time to be rather rare,
so I still assume these patches to correct much more than they break.
And I've marked all new ebuilds to ~ARCH in order to give them some
testing without interfering with stable KDE 3.5 users. If someone wants
to examine the patches more closely, and ensure that they play nice with
Gentoo patches, be my guest.
For a single package, ksvg, the latest securtiy fix committed upstream
seems to be plain nonsense; it refers to an undeclared member and thus
won't even compile. In this case I've dropped the patch from KDE svn and
resorted to applying Debian patches instead. This is of course only a
single package, and there are many more to which there might be relevant
patches in other distros as well. It might be worthwhile to collect
these patches, split them to match the module structure used by Gentoo,
and try to see which of these are relevant, which do apply without
further work, which should be made to apply, and so on. I won't do this
myself, but I'd be glad to provide help and suggestions. If multiple
people want to contribute to such a set of imported patches, a branch in
our shared git repository might be a suitable platform for it, along
with this mailing list. Dunno.