Using KDE 3.5.10 With the Next Official Slackware Release
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I think we should just try to build 3.5 on current (and -64) and see what happens. If it works, we could rather easily provide slackbuilds and eveything would be fine. This way we could have 3.5 on 13.0 (if we have the breath )
What do you think? Maybe I'll try building qt this weekend, if I find some time. If that works, the rest should doable (and it should work).
I don't think you'll need to build qt. It's available in the /extra directory:
check out the other packages available in the /extra/kde3-compat directory. How much more is needed to build KDE 3.5?
If I understand correctly, the packages in /extra are for running 3.5.x apps within KDE4. That is, to provide a 3.5.x compatibility layer within 4.x.
The discussion here is about running 3.5.x without 4.x. Therefore, installing those packages is unnecessary and I'm guessing probably would cause problems.
You may be right, but my impression is that the compatibility libraries are the libraries you'd need to run KDE 3. Just like one can install QT4 and run applications that require it in KDE 3.5 right now. It's not that one is installing some different version of QT4. In other words, the compatibility is provided by the required libraries themselves.
So, I'd think there's no need to build QT3 for Slackware 13, just use QT3 already provided in the kde3-compat/ directory (because it is QT3 build on Slackware 13). The same goes for the kdelibs3-3.5.10 package in the same directory. They are the things that you would build to run KDE 3.5.10 in Slackware 13.
So, after installing those two packages, what's left would be the non-library parts of KDE 3.5.10.
I'd think there's no need to build QT3 for Slackware 13, just use QT3 already provided in the kde3-compat/ directory (because it is QT3 build on Slackware 13).
I agree that rebuilding probably is unnecessary. I'm only saying that installing qt3 from /extra is unnecessary for those already using 3.5.x. For example, those running 12.2. I think those packages are needed only for people running qt3 apps under qt4.
As I stated elsewhere, I updated 12.2 on my testing partitions to 13.0. I did not install the KDE4 or related packages, nor did I remove any of the KDE3 or qt related packages. I never installed any of the compatibility packages when testing 3.5.10 in 13.0. Everything worked.
If somebody is installing 13.0 from scratch but then wants to run 3.5 rather than 4.x, I think the person needs to be sure not to install the KDE4 and related packages. Then install all the KDE3 packages from 12.2.
Some people have talked about rebuilding all the KDE3 packages from within the new 13.0 environment. Somebody far more qualified than me will have to address whether that is necessary or prudent.
Some people have talked about rebuilding all the KDE3 packages from within the new 13.0 environment. Somebody far more qualified than me will have to address whether that is necessary or prudent.
Ah, my mistake. I thought that's what you were discussing with General Failure. I missed your reply to him.
For what it's worth, I think it would be interesting to rebuild KDE 3.5.10 for Slackware 13 and provide the SlackBuild scripts, etc. This would be especially helpful for people who want to run Slackware 13-x64.
Slackware-current uses python 2.6. KDE will not work with python 2.6 without patches. Namely the dcop python bindings (from kde-bindings) needs patched. I'd search Gentoo's bugzilla for the patches.
You can build KDE 3 on -current, install it to /usr/opt/kde3 to match the naming convention of other qt-3 packages in Slackware. Everything works with changing the QTDIR=, prefix=, sysconfig= for the original SlackBuilds.
Here's a patch against the 12.2/sources/kde/ directory to get you started. Get the kdebindings patches, and you're all set You'll need extra/kde3-compat for kde-libs, qca, arts, and qt3. This builds a proper Slackware-current kde3. That way you can install the next version and kde3, rather than 12.2 - upgrade - kludge.
--------
Can't upload .diff, .gz, .tar, .tar.gz so here's the .diff renamed to .diff.txt
how do I use these patch files I tried to use them but it didn't work
where should the source files be where should the patch file be
and what should the patch options be
I've gone back to using bluewhite64 because KDE 4.2 is so bad
Are you guys still wanting to know if/how suspend & resume works on Slack-current? With or without the nVidia binary driver?
If so, I can say this: It worked fine for me on Slack 11 after I spent a couple days fiddling and wrote a script to do the suspend & resume for that. Certain modules cause problems, but I can't remember if nvidia was one of them on my system.
I need to check for my own usage, whether my script still works for Slack64-current anyhow, because XFCE doesn't suspend properly after the 1st suspend+resume, which is exactly what Slack11 did if I used the GUI suspend methods, which is why I wrote the script in the first place.
So anyhow, I'll post back about it in a while or tomorrow, once I verify either way.
how do I use these patch files I tried to use them but it didn't work
where should the source files be where should the patch file be
and what should the patch options be
I've gone back to using bluewhite64 because KDE 4.2 is so bad
Example using the Linux kernel:
Say you've got a kernel patch file called "filename" and you want to patch the kernel.
1) put the patch file into the root of the sourcecode.
2) enter that same directory.
3) type patch -p1 -i filename
4) that's it!
Are you guys still wanting to know if/how suspend & resume works on Slack-current? With or without the nVidia binary driver?... I can't remember if nvidia was one of them on my system... So anyhow, I'll post back about it in a while or tomorrow, once I verify either way.
Sasha
Well, that was easy:
Suspend/resume to RAM works for me, just as fine as it did on Slack 11.
Also, as I have the time (though not necessarily the qualifications ) if I can help out here, like for example taking a shot at patching Ark or something, just say so. If I think I can do it, I'll try.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
Slack64-current suspend-to-ram works
