Chitlesh GOORAH <chitlesh <at> fedoraproject.org> writes: > I don't know in details I didnt have time to have a look at the codes. > And since your patch was failing, ive just removed it during the > build. It's not really practical to try to merge my patch as a patch. The only really practical solution is to redo it: 1. make a copy of the source directory 2. run KFileReplace on it with the kde4home.kfr file in http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-2-specs.tar.bz2 3. scan the changes for false positives and revert these. 4. create a diff. One way to do step 3 is to take a diff, then open both the original and patched directory in Krusader (hooray for 2 panes), and looking at the diff, copy the original file back to the patched directory if all changes in a file are bad, otherwise use Kompare (select the original file on the left and the patched one on the right in Krusader and pick File/Compare by content from the Krusader menu, this fires up Kompare) to revert the bad changes only. There's some manual work in step 3, but it's the highest amount of automation I could attain. Mechanically replacing things like .kde with .kde4 is not a safe change, I tuned the replacements to avoid false positives as much as it made sense, but there's several ones left I can't easily filter out automatically. Be warned that this also means some understanding of what the code is trying to do is required. > The wallpaper willnot be accessible. > I should dig into it later on to enable plasma. As far as I understood, the situation is this: * Kdesktop has been replaced with krunner. * Kicker has been replaced with Plasma. * The desktop functionality (icons, background) has been moved from kdesktop to Plasma. * They replaced (or are replacing, I'm not sure of the exact status) kdesktop with krunner before replacing Kicker with Plasma in SVN. And all this leads to the desktop functionality being temporarily missing. > Kevin if you are working on updated specs, I'm ready to host them and > their srpms. Well, sorry, but I'm more likely to upload 3.80.3 packages with some backported bugfixes. I collected 2 of them already for bugs which annoyed me, if anyone knows a patch in SVN which fixes an annoying bug (NOT a global source change like Oxygen or shared-mime-info or an API/ABI change!), please give me the revision number. (Note that I don't take patches which are not in the upstream SVN unless you have a really good reason why I should (i.e. it's Fedora-specific or required for safe parallel-installability with KDE 3), please get your fixes upstream first!) My plan is that the next version update for my packages will be when KDE releases the next official snapshot. AFAIK, this will be Alpha 1 around May 1st. Why? For one, I don't want to redo my parallel-installability patches all the time. (As you already noticed, and as explained in the first paragraph, simply updating/merging them isn't really feasible.) Updating them for each official snapshot is already enough work. And secondly, I'm using these packages to develop applications (well, currently one application) against them. I need packages with a well-defined API which doesn't change all the time, so I can specify that my CVS HEAD compiles against KDE 3.80.3, not that it may or may not compile against the current HEAD of the KDE SVN trunk depending on the phase of the moon. ;-) See, this is where our needs differ: I'm a developer, and I need the packages as a development platform. Thus I need full parallel-installability with KDE 3 (in particular seamless integration in a KDE 3 session, I'm not going to try to develop in a KDE 4 session, especially not with something like your script which breaks running all KDE 3 apps in the session). And frankly, I couldn't care less about full KDE 4 sessions at this point. I'm most likely not going to run the KDE 4 workspace before it becomes the default KDE workspace (replacing KDE 3). (The way the KDE and Fedora timelines align, that might be as soon as Fedora 8. It will require a rock solid compat-kdelibs3 though.) I also don't really have a use for modules like kdenetwork4, kdepim4, kdegraphics4 etc. at the moment, except possibly for the packages which are new in KDE 4 (like Okular). (I'm not opposed to someone packaging them though, the framework is there with my base packages.) On the other hand, you want the latest and greatest snapshot in order to show users what's the latest from KDE development. This is an entirely different use case. For example, a script like your startup script works for you because you want to show only KDE 4 apps anyway, not KDE 3 ones. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
