Konsole was installed in gnome with the dependencies libidn and kdelibs. When konsole starts, everything seems okay. This message is : QPixmap: Cannot create a QPixmap when no GUI is being used. When one wants to configure the konsole, nothing happens and an error message is listed in the gnome-terminal used for launching konsole. This message is : kcmshell (kdelibs): WARNING: Could not find module 'kcmkonsole'. Reproducible: Always Steps to Reproduce: 1.emerge konsole libidn kdelibs 2.konsole as command line in gnome-terminal 3.\ Settings \ Configure konsole 4.Error message in the gnome-terminal Actual Results: Nothing, except that I can't configure the konsole... Expected Results: The software should have opened the GUI for configuring the konsole. My computer runs with the kernel 2.6.10-r5 and with Gnome. I emerged konsole and its dependencies because I was unable to make accents in my gnome-terminal running either in tcsh or bash. After emerging, I am able to do those accents in bash only, but not only in the konsole, but also in the gnome-terminal... Anyway, tue problem is I would like to use the konsole and also configure it to be more beautiful...
Thanks for reporting this. In fact kcm_konsole code is inside kcontrol directory and not from konsole. (so for now you can emerge by hand also kcontrol) kde team: Do you think that making KMEXTRACTONLY=kcontrol/konsole in kcontrol ebuild and compiling it in the konsole ebuild will be better? If you are right, do you think that the same should be done also with other programs like konqueror?
I think the kcontrol ebuild should be 'broken up' into: - kcontrol ebuild: just the kcontrol binary - kcontrol-modules ebuild: all base/general modules that don't have heavy deps - any module that configures a specific application (eg konsole) moves to that app's ebuild - Optional: there might be reasons to separate some modules out of kcontrol-modules and into their own ebuilds, but for now we can probably wait until someone actually requests that. I say this because we still have a nonzero cost in raising the number of packages built - this will be rectified with confcache + (in my opinion, at least) per-app tarballs with pregenerated configure scripts etc. Also, ebuilds like konsole shouldn't depend on kcontrol in this new scheme, since kcmshell comes with kdelibs. This would apply to several other split ebuilds that currently depend on kcontrol.
Ah, and if we're going to do this, we should do all of it at once. Every such change will require a new rev of kcontrol and a change in the other ebuild (konsole in this case) to depend on >= the new rev to prevent file ownership conflicts... If noone is against this, I'll do it.
Dan, just don't add more ebuilds. I also dislike the expostion of every single kdeaddon plugin. I don't need every single plugin either, but it's really not worth it, imho. I think e.g. all the *-kate plugins should become kdeaddons-kate. Beside the efforts to maintain the stuff in future, without the splitted kde ebuilds `emerge --pretend --update --deep world` took a bit more than 20 minutes. Now it takes more than one hour on my box.
You're opposed to just what I marked 'optional', right? I don't want to do that now either - for reasons of performance too, although slightly different ones from yours... So how about just moving modules like konsole's and konq's to their apps' ebuilds? That's all I want right now. Splitting the kcontrol app from the main group of modules isn't important. In fact it should probably be lumped together with the other stuff marked 'optional', as long as adding ebuilds has nonzero cost... It's true that the split ebuilds exposed (to me) scaling problems in unexpected areas, like repoman scans and, now, ebuild cache generation. When I started all of this I was only thinking about time to emerge a package... To make the cost of new ebuilds near-zero, we need at least confcache. The next stable version of portage that'll include confcache will also have lots and lots of speedups, but I'm not following portage development anymore... Anyway, we can reevaluate that then. I also agree that some groups of ebuilds, like most kdeaddons subdirs, might be joined back together, since each one is very small and carries no extra deps. OTOH, some kioslaves packages (kdebase and kdemultimedia) have accumulated lots of deps and perhaps separating just one or two new ebuils from each of these would alleviate that pressure a lot. As I've said before, the decision which things to split (eg kate plugins) and which to keep together (eg all kioslaves groups, all kdeartwork subdirs) was somewhat arbitrary.
To clarify: without the 'optional' stuff (remote future, forget about it) all I want to do is move modules around like Simone proposed, for both konsole and all other apps in this state (eg konqueror).
>You're opposed to just what I marked 'optional', right? Right, better I raise my voice now, instead when it is too late. One or two ebuilds more ore less wouldn't matter anyway. :) btw. confcache will not help to speed up the operation I mentioned above afaik, or does the code patch include code to speed up dependency calculation, too?
No, it's just that the delopvement version of portage includes some unrelated ebuild-parsing speedups. The daemonized ebuild.sh and such... But as I said I'm totally not uptodate on the state of CVS HEAD of portage, and besides there's still an estimated half-year until the development branch gets a stable release so a lot of new stuff might go in.
Just a question, is this related to my konsole suddenly wanting to pull in half of KDE during emerge world -uD ?: shogoki konsole # emerge -p konsole These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] kde-base/kdelibs-3.5.2-r6 [3.5.5-r5] USE="-pertty%" [ebuild N ] kde-base/libkonq-3.5.2 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" [ebuild N ] kde-base/kdebase-data-3.5.2 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" [ebuild N ] kde-base/kicker-3.5.2 USE="xcomposite xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" [ebuild N ] kde-base/kdesu-3.5.0 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility -kdexdeltas" [ebuild N ] kde-base/khelpcenter-3.5.2 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" [ebuild N ] kde-base/kcminit-3.5.0 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility -kdexdeltas" [ebuild N ] kde-base/khotkeys-3.5.1 USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" [ebuild N ] kde-base/kcontrol-3.5.2 USE="opengl ssl xinerama -arts -debug -ieee1394 -kdeenablefinal -kdehiddenvisibility -logitech-mouse" [ebuild R ] kde-base/konsole-3.5.5 I am using gnome and have -kde in my USE flags, so I don't think I want it to pull all this in. Konsole is installed only because I also use KDevelop, which pulled in konsole long ago. Everything (I need) seems to be working fine, so if at all possible please enclose this: > # For kcm_konsole module > RDEPEND="${RDEPEND} > kde-base/kcontrol" in a USE flag.
No, konsole needs that for settings. Closing this bug too.
