KDE4 Overlay (Part 5)

[Philantrop]

This is the fifth part of the support thread for the KDE4 overlay. You'll find part 1 here, part 2 here, part 3 here and part 4 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

1. Read the docs (details below). We reserve the right to kick you where it hurts if you don't. ;->
2. We're not responsible for any damages these ebuilds can do to your computer.
3. 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.

For live ebuilds, we're going to switch 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.

[wrc1944]

My screen resolution problem with krandr described on p.29-30 in part4 of this thread is still there after today's complete kde svn update. Nobody else has seen this type of problem? I have it both on Gentoo and Arch kde svn.

I'm having a hard time understanding why krandr would be changed by removing this code in krandrmodule.cpp:

Code: Select all

void KRandRModule::performApplyOnStartup()	 
	 {	 
	         KConfig config("krandrrc");	 
	         if (RandRDisplay::applyOnStartup(config))	 
	         {	 
	                 // Load settings and apply appropriate config	 
	                 RandRDisplay display;	 
	                 if (display.isValid() && display.loadDisplay(config))	 
	                         display.applyProposed(false);	 
	         }	 
	 }	 

specifying "ApplyOnStartup." Maybe there's a good reason I'm not aware of, but apparently this makes it impossible to retain a simple 1280x1024@75 setting on a 19" CRT monitor. Upon restart, it continues to revert to a 17" size of 1280x1024@74.9, no matter what you have set in the relevant .kdesvn config files. Unless I'm mistaken, this happened as of revision 763267, Sat Jan 19.

I guess I'll adopt mikedee's suggestion, and disable krandr in xorg.conf for the time being, as it doesn't look like this is going to be fixed any time soon.

[gimpel]

but apparently this makes it impossible to retain a simple 1280x1024@75 setting on a 19" CRT monitor. Upon restart, it continues to revert to a 17" size of 1280x1024@74.9

I fail to see the difference

[wrc1944]

gimpel,
At 1280x1024@74.9 which is what krandr always reverts to (I guess at it's default), the actual display is the size of a 17" monitor, with about 3/4 of an inch solid black border surrounding it on my Gateway EV910 19". At 1280x1024@75 (which I have used for years on this monitir), my entire screen is filled with the normal display.

EDIT: Why is that first 1280x1024 setting I typedshowing up on the forum as an html link? Only difference is 74.9 instead of 75.

[gimpel]

Only difference is 74.9 instead of 75.

That's also exactly the point where I failed to see the difference. Do those 0.1Hz really make the difference from 19" to 17"? o.O

It's shown as mailto: link because something@foo.moo is mailto syntax (<- see?)

I have only one display size configured in xorg.conf, so there is nothing for RandR to revert to or change, infact RandR is pretty useless here

[wrc1944]

gimpel wrote:

That's also exactly the point where I failed to see the difference. Do those 0.1Hz really make the difference from 19" to 17"?

Yep- 0.1Hz makes the difference- ridiculous, isn't it?

I see what you mean on the mailto syntax. Thanks.

mikedee- your suggestion about putting this in xorg.conf didn't work. On reboot, or just restarting kde it still reverts to the wrong krandr setting- in fact, why would krandr even start up?. How can I get rid of krandr?

Code: Select all

Section "ServerFlags"
Option "RandR" "false"
EndSection

[mikedee]

I think that if you do not have randr enabled then you have to set the resolution in your xorg.conf. Try using ModeLines to get the right refresh rate.

I haven't actually tried that myself but it should work.

[wrc1944]

Even with your Server Flags suggestion, krandr still comes up, and is running, which I don't understand. I've had the correct mode line all along. My xorg.conf works fine with xfce4, Gnome, whatever- so it's not the xorg.conf file. Besides, I've already tried editing it many times even though I knew it was correct. Also tried using many other xorg.conf files from other distros known to work on this hardware, for years, with no luck. It seems like krandr has taken over my system, even over-riding my xorg.conf file. Also, I can't edit some of the relevant config files in .kdesvn/share/config- they are always reverted on a restart.

IMO, it's what I already mentioned, about the kde devs removing that code in the
krandrmodule.cpp file. There seems to be no other reasonable conclusion.

Other than commenting krandr out in the CMakeLists.txt file, and recompiling kdebase, is there any other known way to get rid of krandr?
If we were using split ebuilds in kde svn, it'd be easy.

EDIT: OK- I did emerge -C xrandr, and removed it. On a shutdown/reboot, krandr with the wrong resolution/refresh rate still comes up, and I can still change it back to @75 instead of 74.9, and get my normal display. I thought krandr was simply a front-end to xrandr- is that not correct?

[mikedee]

Did you try removing x11-libs/libXrandr?

xorg-server does not depend on it so maybe you can recompile it without libXrandr. BTW - What does xrandr output from a terminal?

[wrc1944]

Hmmmmm.. I removed xrandr-1.2.3.
xrandr output is "command not found"

Equery l shows libXrandr-1.2.2 installed, so I'll remove that, too.

EDIT: After I did the above, I recompiled xorg-server. On restartX, I got a black hung screen- had to cold reboot, and still couldn't get X to start. Tried xfce4, but same result. Errors were libXrandr.so not found. Anyway, I had to remerge xrandr and libXrandr, then I could reboot to kde svn. Everything is back to the "normal" problem I have described.

Apparently, I can find no solution to this at the present time, and I'll just have to live with resetting back to my normal 1280x1024@75 every time I start the box. I'm out of ideas, other than editing back in the removed code in krandrmodule.cpp, and see if that restores the ability to retain my setting on startup.

[mikedee]

Maybe report it as a bug, at least you only have a single screen so there response is not something like 'do you KNOW the state of multi-head on Linux? good luck with that one!'.

You would have to reinstall xrandr to see the console output, for me that is wrong so it isn't a problem with KDE.

[Cephalon]

people since today i have the following problem

Code: Select all

sudo layman -a kde
* Running command "/usr/bin/git clone "git://www2.mailstation.de/git/genkde4svn-pub.git/" "/usr/portage/local/layman/kde""...
Initialized empty Git repository in /usr/portage/local/layman/kde/.git/
fatal: read error (Connection reset by peer)
fetch-pack from 'git://www2.mailstation.de/git/genkde4svn-pub.git/' failed.
* Failed to add overlay "kde".
* Error was: Directory /usr/portage/local/layman/kde does not exist. Cannot remove the overlay!

please help!!!

[gimpel]

Same here. Seems it's blocked somehow, as their gitweb is working and shows activity.

Really annoying ... ^C'ing syncs sucks.

[yokem55]

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

I'm hoping that by the time that point comes that pkgcore will be also supported. Frankly, everytime I've looked at moving to Paludis, I've been rather turned off by the attitudes of the developers, and I would rather go without the svn builds than put up with it.

[wrc1944]

mikedee wrote:

You would have to reinstall xrandr to see the console output, for me that is wrong so it isn't a problem with KDE.

Jut to clarify, if you mean the kde app "konsole," my problem was I couldn't get X to start, because it apparently for some unknown reason insisted it needed libXrandr, even though I had recompiled xorg-server after removing it. Maybe I needed to recompile every single modular X11 package? I could log in to terminals OK, so I could fix it up.


yokem55, I don't necessarily agree about the " the attitudes of the developers," but I do kind of worry about being forced to go to paludis to keep using kde svn. Maybe it will turn out to be no big deal, but after wading through the Documentation pages I must say I have no real desire at this point to stop using Gentoo's regular portage and emerge. Using both concurrently seems like sort of a PITA, however, I could be wrong, and am willing to be convinced. Hopefully, there will be a pretty easy way to implement this, and they'll post a fool-proof "do this" 1,2,3... when the change comes.

For keeping up with kde svn, there is another very good option. On Arch, I've been using the kdesvn-build script for a few months, as my main user. You compile and install everything, including qt-copy in your home directory, however these are the defaults, and can be altered in the .kdesvn-buildrc script, which can be heavily customized.

One downside is you need a lot of room in /home/user to build and install to, but you can set an option not to save the build files, and also to use your distro's qt-4.4, which saves a lot of space. However, not saving the build files (the default) does disallow one great feature of this script, which allows only re-building the files which have actually changed, and not having to recompile entire monolithic packages each time. Saves a lot of compiling time. Anyway, if you use the defaults, you'll need 12-15Gb free space, otherwise when all the space is used, the building process aborts.

I've had good results, and wind up with a kde svn install on Arch virtually identical to the one on Gentoo, however I prefer using Gentoo and ebuilds/portage. I'm not necessarily advocating one or the other, but just mentioning this in the Linux tradition that there is another viable option.
http://techbase.kde.org/index.php?title ... esvn-build
http://kdesvn-build.kde.org/documentation/

[yokem55]

Well,
Here's what I'm talking about when it comes to the attitudes of the Paludis Developers: I went ahead and installed Paludis this morning via portage, and the first message I get after it's built is:

Code: Select all

 * Your MAKEOPTS -j is too high. To stop the kernel from throwing a hissy fit
 * when g++ eats all your RAM, we'll use -j1 instead.   

Now, I use distcc to distribute compiles across my network, and the way to make that work on the client end is to set MAKEOPTS to -j$HIGHERTHANISNORMALLYSANENUMBER. But the Paludis ebuild doesn't even bother trying to figure out if that's the case, assumes that I must be an idiot, and overrides my usually well thought out settings by fiat. If they had said "Compiling Paludis requires 512mb of free memory per make job to avoid crazy swapping. We see you only have $FREEMEMORY available, so we're changing your MAKEOPTS to -j1. If you are using distcc or otherwise know what you are doing, you can override this by setting I_KNOW_WHAT_THE_HECK_IM_DOING=1", I probably wouldn't be complaining about developer attitudes.

Now I'm the first person to admit that portage sucks and needs to be replaced, but I'd rather not use software from folks that assume that I'm an idiot. I'll probably still eventually switch, but I'm not exactly going to enjoy it.

[madcat87]

I switched to paludis yesterday without problems.Now I ditched layman and arranged all my repositories in one folder.Its a lot tidier now. I am even thinking of unpaluding portage altogether.It takes some getting used to the new commands and the stdout thought.

[dleverton]

Here's what I'm talking about when it comes to the attitudes of the Paludis Developers: I went ahead and installed Paludis this morning via portage, and the first message I get after it's built is:

Code: Select all

 * Your MAKEOPTS -j is too high. To stop the kernel from throwing a hissy fit
 * when g++ eats all your RAM, we'll use -j1 instead.   

Wow.

[Kate Monster]

Hello,

Kopete is not showing support for AIM, which I need. Which USE flag do I need to enable for this to work?

[heirecka]

Kopete is not showing support for AIM, which I need. Which USE flag do I need to enable for this to work?

"oscar" enables support for AIM and ICQ

[wrc1944]

madcat87,
If it's not too much trouble, could you please post a brief 1,2,3...... of the steps you used to make the change to Paludis?

Judging from your post above, am I correct in thinking you are only using it for all the KDE SVN packages currently in layman kde, and there are no conflicts with portage and /etc/make.conf, etc used for other system/world stuff?

yokem55,
I see what you mean.

[madcat87]

Well I just read that http://paludis.pioto.org///overview/gettingstarted.html and used the portage2paludis script to convert my /etc/portage configuration to /etc/paludis/.
/etc/make.conf is not used but is replaced by /etc/paludis/use.conf and the CFLAGS are in /etc/paludis/bashrc
The only thing that is more different is how repositories(overlays) are handled.Every one has a file in /etc/paludis/repositories (including the main gentoo repo).Also they all are synced together.
Iam using it for everything.You could also use portage but then you must rebuild the cache with paluds.

[wrc1944]

madcat87,
Thanks much!

[enzobelmont]

how can i install macos widgets on my plasma desktop??

thanks in advance.

[IamtheOne]

Even with your Server Flags suggestion, krandr still comes up, and is running, which I don't understand.

krandr doesn't have anything to do with your xorg configuration other than it requires randr to be enabled to function. (xrandr is a commandline alternative to krandr aka it does the same thing basically)

If you want to stop krandr from starting up on login you should open up systemsettings and go to the autostart section and disable it. If that doesn't work, try simply exiting the tray icon; log out and back in, it shouldn't come back until you open it again manually.