KDE4 Overlay (Part 6)

jmbsvicetto · Posted: Sun May 04, 2008 6:30 am Post subject: KDE4 Overlay (Part 6)

This is the sixth part of the support thread for the KDE4 overlay. You'll find part 1 here, part 2 here, part 3 here, part 4 here and part 5 here.

The KDE overlay contains live ebuilds for KDE4 trunk. The regular KDE 4.0.0 ebuilds are now in the official Portage tree.

The overlay is maintained by:

Wulf C. Krueger - Philantrop (philantrop at gentoo.org)
Ingmar Vanhassel - Ingmar (ingmar.vanhassel at gmail.com)
Bo Ørsted Andresen - zlin (bo.andresen at zlin.dk)
Timo Gurr - Psy (tgurr at gentoo.org)
Tobias Heinlein - keytoaster ( keytoaster at gentoo.org )
Jorge Manuel B. S. Vicetto - jmbsvicetto (jmbsvicetto at gentoo.org)
Bernd Steinhauser - berniyh (gentoo at berniyh.net)

IMPORTANT NOTES

Read the docs (details below). We reserve the right to kick you where it hurts if you don't. ;->
We're not responsible for any damages these ebuilds can do to your computer.
Do _NOT_ report bugs on Gentoo's bugzilla.

You'll find us on Freenode in #genkdesvn and, sometimes, here if you need help. We definitely prefer IRC, though.

To check the overlay Documentation look at the README and ReleaseNotes files and the /Documentation directory in the overlay tree. The KDE 4.0 live packages have been slotted and shouldn't cause any problems with the 3.5 slot.

Note from the maintainers of the live ebuilds:
For live ebuilds, we've switched to a new, improved ebuild format. Read on to learn what this means for you.

For quite some time now, our progress has been impaired by the absence of advanced features that have not yet been implemented in Portage.

Most of us who are working on the overlay have been using alternative package managers (PM) for quite some time now. Thus, the idea arose to go a step further and actually make good use of the capabilities they offer us and create new, improved ebuilds.

For users of the KDE overlay's live ebuilds the this means you will have to use Paludis once we have switched.

You can find all the details in this email.
_________________
Jorge.

Your twisted, but hopefully friendly daemon.
AMD64 / x86 / Sparc Gentoo
Help answer || emwrap.sh

fldc2 · Posted: Sun May 04, 2008 9:57 am Post subject:

I found the problem with strigi not starting using the sopranobackend, strigidaemon won't look in /usr/kde/svn/lib64/strigi where the ebuilds like nepomuk from the kde overlay installs stuff, instead it only use libraries in /usr/lib64/strigi.

So where is the best place to fix this? Strigi or some of the packages installing to this dir?

wrc1944 · Posted: Sun May 04, 2008 11:50 am Post subject:

Berniyh,
Many thanks. That worked.

Rebuilding automoc allowed akonadi to build, which allowed kdepimlibs to build. I'll sure remember the automoc rebuild problem if I see that type of failure again. :wink:

Re-sync'd everything, and am starting a complete kde rebuild. If I get back a working desktop, I think I'll wait a few days before trying another update, so I can at least enjoy it for a little while before I break it again. :lol:

_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

wrc1944 · Posted: Sun May 04, 2008 3:26 pm Post subject:

Well, all 88 of 88 packages compiled with no problems, so I thought I was finally OK.

No such luck. :cry:

On reboot to kdesvn, I got a plasma/workspace crash, but it immediately reset itself, and the destop looked normal. Dolphin launched normally. Konqeror as webbrowser or file manager won't launch. More seriously, trying to launch Opera results in a locked grey screen- no way out but reboot. Here's the rather sparse details from the plasma crash dialog box. Should I try a plasma and/or konqueror rebuild? Or do I have to do the whole qt rebuild again first, and then the whole kde-scm rebuild once again?Or maybe try a reconcilio first?

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

It's sounds like Plasma is broken.
For plasma normally it should be enough, if you do

wrc1944 · Posted: Sun May 04, 2008 7:20 pm Post subject:

Berniyh,
Tried rebuilding libplasma and plasma, rebooted- same thing happened. Tried rebuilding konqueror, same problem. I can start Opera from a konsole, but under it is the grey screen, so if i close Dolphin, Opera, konsole. or any open app, that's it- I'm left with a locked grey screen, and I can only do ctrl-alt-backspace and restart X, where I'm left at my gdm login screen, which works. :cry:

Yesterday, as I mentioned, I rebuild qt-split fine, and first thing today all of kde fine (after akonadi and kdepimlibs compiled OK), so I should be fine, but I'm not.

EDIT: Forgot- Right after the desktop comes up (3-4 seconds), a little white box flashes in the right upper corner of the screen, then the desktop goes black 2 seconds and re-sets itself and appears normal again, but the little white box is now gone and a very small krandr icon is in the upper left-hand corner of the screen, and will open the display settings found in sytem settings.

Guess I'll try removing .kdesvn- forgot to try that.

EDIT2: That helped some. Opera no longer crashes the screen- I can use it fine. That krandr thing is gone. No workspace/plasma crash on kde starting up now. Dolphin works, but konqueror is still not launchable. kdf launches, but seems to cause a brief plasma crash/grey screen that somehow immediately corrects itself back to normal, and kdf is still there, functioning.

Weird stuff- I'm sure there are more apps will cause weird stuff to happen. Apparently, I can use Opera, konsole, and Dolphin without problems (so far)- at least that's a somewhat functional desktop. :roll:

_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Stefano Crocco · Apprentice Joined: 28 Sep 2006 Posts: 157

Since today, I'm experiencing a strange (and very annoying) issue when building any kde package. The compilation process goes on without problems and the program is installed correctly. At the end of the installation, the keyboard almost stops working from within kde. Almost means that the Alt+Ctrl+Backspace combination still works, so that I can kill the X server (I could log out correctly with the mouse, but this issue makes me so angry that I don't have the patience to do it) and go back kdm, where the keyboard starts working again. I think that this issue may be related to this other fact I started noticing today: at the end of the installation process, paludis fails when it tries to run kbuildsyscoca (this failure doesn't make paludes itself to fail, though). The error message is something like "xlib: connection to 0:0 refused by X server" (I can't be more specific because at this point the keyboard stops working, so I can't copy the message). Has anybody met something similar?

Another issue, this time with paludis (I'm still quite new to it). The keywords.conf.d/* and package_unmask.conf.d/* in the repository unmask all packages in the kde4-experimental repository, including things like amarok-scm and kdevelop-scm which are quite unusable at the moment (at least, they were last time I tried them). Doing

wrc1944 · Posted: Sun May 04, 2008 8:38 pm Post subject:

I've noticed the "xlib: connection to 0:0 refused by X server" too. I wondered about it, but never tried to figure it out, as I'm having other weird problems and sort of forgot about it. However, I have not noticed any problems like you describe, or any others I would think would be related- but at this point what do I know? :wink:

Does anyone have something called NepomukServices using 96% cpu, and quickly building up to about 190mb of ram (takes about 5-8 seconds), and then suddenly releases the memory completely, and starts building up ram usage again. It repeats this endlessly, no matter what app is open, or none at all.

It's not listed in the Service Manager, and doesn't seem to be related to any program I use. Why is it even running at all? Can I somehow disable this monster resource hungry renegade "service"? In System Monitor it is listed, and I can right click on it, and there's an option to kill that process. My question is, do I need it for something I'm unaware of?

One of my sticks of ram went bad two days ago, so I only have 512mb on this box, and using (wasting) almost 200mb needlessly is a big deal for me right now.

EDIT: Hmmm. Trying to kill NepomukServices via System Monitor didn't work- the thing will not die.

Does this mean it is a vital system service? That can't be right- it's eating 96% cpu constantly.

Aha! Had to kill nepomuk server, not services. Now I'll see what goes wrong. :wink:

Anyone know why that thing would apparently be running wild by default? I surely never enabled it.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

creidiki · Posted: Sun May 04, 2008 8:55 pm Post subject:

Stefano Crocco · Apprentice Joined: 28 Sep 2006 Posts: 157

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

Stefano Crocco · Apprentice Joined: 28 Sep 2006 Posts: 157

wrc1944 · Posted: Sun May 04, 2008 9:54 pm Post subject:

Trying to start konqueror as user from konsole gives me this output, if it will help figuring this out.

wrc1944 · Posted: Sun May 04, 2008 10:18 pm Post subject:

Is the following causing that runaway system resource nepomuk problem I mentioned above?

In system settings, under, Nepomuk/Strigi Server Configuration, it has the Nepomuk semantic desktop enabled by default, along with a "Strigi desktop search" and the strigi running button is green.

This sounds like something similar to Beagle, or the windows file indexing crap which was always on by default, slowing down the entire system's performance. Is this correct- that is what this stuff is?

If so, and you don't want all that stuff running in the background, is it OK to entirely disable nepomuk and strigi. I for one have never had a good use for such resource drains. IMO, for my desktop usage, stuff like this is basically useless. If I had a super-fast system, it might not matter, but with what I have now, it is just awful.

I disabled Nepomuk server (and services), and sure enough, my system is now much more responsive- For example, Dolphin and other apps open instantly now- use to be 1-3+ seconds.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

franzf · Advocate Joined: 29 Mar 2005 Posts: 4565

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677

Stefano Crocco · Apprentice Joined: 28 Sep 2006 Posts: 157

Cephalon · n00b Joined: 04 Nov 2007 Posts: 23

Hi, i am new with paludis and i have the following problem, please help me!!!

Stefano Crocco · Apprentice Joined: 28 Sep 2006 Posts: 157

Another issue I'm having since yesterday is not being able to build kdepimlibs, because of an app-office/akonadi-related problem. The error message I get is:

PurpleGecko · n00b Joined: 16 Sep 2007 Posts: 14 Location: Germany

I have also had some problems with keyboard lockups when compiling KDE from svn. It has happened now twice during compiling from KDE today. I have been able to trace it down to kded4 daemon locking up on me for some reason. After killing the kded4 daemon I am able to use my keyboard again without any problems. (Last time I noticed that the control key seemed to be locked somehow....as mouse scrolling caused the font-size to change in various windows...and ctrl-alt-f1 still worked fine... and from there I was able to kill the daemon without and problems.) It is possible that it is due to newer version of kded4 being needed or some changes due to compiling and running the same program.

Not sure if that will help anyone...just my observations here

beso_1717 · Apprentice Joined: 19 Jul 2007 Posts: 263

i was googling around for quite some time but weren't able to find anything about using kde4 on xorg-server compiled from git. has someone been able to use it that way?!

thanks.

Berniyh · l33t Joined: 07 Jun 2006 Posts: 677