Yeah, kdepim nailed to semantic-desktop. It is not a problem for me, because I don't use any of these "helpers" (kmail, korganizer, kalarm and so on). I can manage my desktop and organize my life myself.

Without overlay it may be boring to do the things I did before on every update. But I think it worth to wait until 4.11 appears. Seems like a lot of changes will be included (regarding semantic).

But I do not want to remove amarok or replace him with other player as it was suggested before. So I have no options except editing kdelibs ebuild. May be worthwhile to change the amarok ebuild instead of kdelibs, I do not know. Anyway I changed kdelibs ebuild and updated a system successfully. Without having to enable semantic-desktop.

Fair enough. Missed the bit about wanting amarok. Where as I consider losing amarok an acceptable loss for not having semantic desktop.

I am away from home at the moment. I think it was stevel above who wondered about package.provided. That is something I wanted to try as well when i get home. The other thought is just move to another de/wm. Lxde and razorqt are close enough to what I am used to. I could live with xfce if I had to. When building a new image the 1st wm I install is windowmaker because it is quick to install and fast.

Even disregarding semantic-desktop the difference in how fast the desktop feels compared to alternatives has been enough for me to trial other desktops._________________Beware the grue.

I used to use kde but as the semantic desktop stuff nearly killed the performance and responsiness of the machine, i totally swithed to xfce. I made a stop ant cinnamon, but it depends on gnome and gdm. Leonard ware. After reconfiguring xfce, i feel "at home"

Yeah, kdepim nailed to semantic-desktop. It is not a problem for me, because I don't use any of these "helpers" (kmail, korganizer, kalarm and so on). I can manage my desktop and organize my life myself.

Yup, so let's forget about trying to make it work.

Quote:

Without overlay it may be boring to do the things I did before on every update. But I think it worth to wait until 4.11 appears. Seems like a lot of changes will be included (regarding semantic).

Turns out Duncan is already ahead of us. Interesting ebuild-patch approach, which I like but not in the end-user overlay, just as a process to derive the overlay ebuilds.

It really is a shame though, that both the gnome and KDE teams seem to be moving in a direction where you can't even use any of their apps without their bloated crap. Until this issue came up, I never even knew what all this crap even was...semantic-desktop, nepomuk, etc, etc. To me it was just stuff I knew I didn't need that I was constantly fighting off. When I read what it was all about, I was stunned at how much it all just sounded like a bunch of crap. I think the KDE team has a terminal case of buzzworditis (or more accurately, self-importance I think). They've totally lost site of the beauty of simplicity that's for sure. That's the main thing that attracted me to Linux, and especially Gentoo, in the first place...being able to have a system that does what I needed in a way where I actually have a good idea as to what's going on under the hood. Gnome and KDE seem to be hell bent on becoming the polar oposite...a Windows-like bloated black box. Amazing.

This.

I've had KMail 2 crash on me for the last time. KMail was my main reason for staying with KDE, but when it went the way of Amarok (from great to useless in the 1.x -> 2.x process), there really are no reasons to continue with this bloated crap that KDE has become. I think I'll go for LXDE; it looks like a desktop that I can use.

And, to answer the question in the title of this thread: it's probably the only way to opt out of the semantic desktop._________________The Yggdrasil Genealogy Project

1. For ripping CDs I can suggest rubyripper. It depends on ruby, but otherwise it is an excellent CD ripper.

2. For mounting stuff with no dependence on udisks, I can suggest udevil. It can depend on udisks if you have udisks installed. Otherwise, it falls back to kernel polling. I use the latter mode and have removed udisks from my system._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

If you want to change the situation actively, it is now the time to step up

This is where I am. I've got patches that remove the dependencies that udisks2 and upower have on polkit. The modified upower works fine with KDE, but because there is some secret handshake between KDE's notification system and polkit before KDE will even attempt to talk with udisks2, I still don't get drive-insertion notifications in KDE. I've started my foray into the kdelibs source to figure out how to break its thralldom on polkit.

I'm finding much more about KDE innards than I thought I would (and it's a slow slog). Because of this, I think that once I've figured out how to make udisks integration work in KDE without polkit that I will next look into how to stub out the Nepomuk functions so I can build KDE with a dummy Nepomuk.

A really nice thing that distinguishes KDE from Gnome is that KDE explicitly targets non-Linux systems. KDE components like Solid and Phonon exist to abstract out the DE's interactions with OS-level libraries. If they keep this up (and this sure looks like the trend), they will never have hard dependencies on systemd or the kits. The architecture is already there to allow for alternative interfaces--even in Linux, and even if you have to write your own.

BUT--the components that come standard as a part of KDE are harder to break out. The KDE maintainers tend not to consider these to be optional. They seem to have a heartfelt commitment to Nepomuk--even if tons of KDE users think that KDE would be just great if they left Nepomuk out. Since the trend is to expand the range of KDE components that overshare their application data with Nepomuk (which is the thing that makes it ever harder to implement a semantic-desktop USE flag), I think the best solution would be to patch Nepomuk so that it would act like /dev/null. And since /dev/null doesn't need a lot of dependencies (grin), things like the databases would just stay out of the build. KDE programs could still talk to Nepomuk, but it would be mighty forgetful.

Well, I'm still waiting for Duncan atm. He said he'd have something a couple of weeks ago, then said he's busy. Now he's discussing it on the ML, in great detail, but still hasn't taken 5 minutes to post the patches to KDE ebuilds which he's several times said he's been running for a while now. So it's kind of hard to collaborate with him, though there's lots of cruft on the mailing-list discussing what he's done, just no actual patches nor scripts. Hopefully he'll reschedule his priorities soon, but if not I'm not going to hang around and wait for him to produce nothing.

I'll upgrade to 4.10.5 soon, then setup an ebuild-patching script (which is not hard) for the next set of changes. I've arranged an overlay and two trac + git repo combis for this, because there is simply no way I will be using semantic-craptop, and I'm not ready to give up KDE after it finally started working decently again in 4.9.

I'd encourage anyone else who wants to keep running 4.x the way they like it, not to lose hope. Clearly the patching mechanism is feasible, and is not very difficult. The hard part will be figuring out what patches we need, especially when that's to the underlying codebase. But again, KDE runs on BSD, so it's not like the core system cannot cope without it: Qt runs practically everywhere in device terms, and KDE is, and always has been, a showcase for Qt.

I have faith in the collective knowledge and experience of Gentoo users: for instance, all the Gentoo developers had given up on hardened a few years ago, until users got it into shape by doing all the work. In comparison, this is trivial.

I've arranged an overlay and two trac + git repo combis for this, because there is simply no way I will be using semantic-craptop, and I'm not ready to give up KDE after it finally started working decently again in 4.9.

According to the link which posted, the gentoo KDE-team might agree to put the patches in the main tree: I'd suggest to cooperate with them instead of putting up an overlay which regularly needs to be patched: It would be much better to have a masked.forced semantic-desktop flag (which the user can change on his own risk) in gentoo-maintained ebuilds with user contributions than a separate overlay with patches and hacks.

According to the link which posted, the gentoo KDE-team might agree to put the patches in the main tree: I'd suggest to cooperate with them instead of putting up an overlay which regularly needs to be patched:

All that link says is that if someone is prepared to put in the work and maintain it, then they'll use it. You have to put in the work first, and prove that your work is sound. The only way to do that is via an overlay.

Quote:

It would be much better to have a masked.forced semantic-desktop flag (which the user can change on his own risk) in gentoo-maintained ebuilds with user contributions than a separate overlay with patches and hacks.

What "hacks"? You're suggesting we maintain patches; how can we do that, if we don't actually change anything?

Unqualified aspersions like that aren't very useful, even if they are popular.

All that link says is that if someone is prepared to put in the work and maintain it, then they'll use it.

That is what I meant: If you are prepared to maintain it, it is time to step up and tell the developers.

Quote:

You have to put in the work first, and prove that your work is sound. The only way to do that is via an overlay.

Not necessarily. Of course, some patches must exist already, then it is mainly a topic of being convincing in discussion. Of course, it is clear that the developers would not be satisfied with a one-shot patch on the long run.

Quote:

What "hacks"? You're suggesting we maintain patches; how can we do that, if we don't actually change anything?

Better to maintain them in the main tree than in an overlay: As long as they are in an overlay, they remain hacks which will be ignored by most people, including the gentoo kde team.

Quote:

Unqualified aspersions like that aren't very useful, even if they are popular.

It is not an aspersion, it is how it is observed: Continuously patching upstream (here, upstream means: gentoo kde team's ebuilds) will hardly be a living project on itself. A "fork" of a part of a distribution remains a hack even if it should become popular.

Better to maintain them in the main tree than in an overlay: As long as they are in an overlay, they remain hacks which will be ignored by most people, including the gentoo kde team.

Yeah, it would be the best way to put them into main tree and maintain them here , but I think these patches will be ignored by devs, regardless where they located: at main tree or at overlay or somewhere else.

I see that kde 4.11 has made its way into portage. I will not run a semantic desktop crippled KDE, but I haven't had time yet to explore alternatives like xfce. So, I need to buy some time. What is the shortest and sweetest way to mask it and prevent any of this stuff from being installed on my systems?

I see that kde 4.11 has made its way into portage. I will not run a semantic desktop crippled KDE, but I haven't had time yet to explore alternatives like xfce. So, I need to buy some time. What is the shortest and sweetest way to mask it and prevent any of this stuff from being installed on my systems?

should prevent any kde related package to get upgraded since it will prevent the kdelibs from getting upgraded._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

I'm not sure what to make of that.

EDITED TO ADD: I see the same error when using /etc/portage/package.mask/kde-4.11.mask.

My usage scenario certainly does not rely on semantic-desktop and I don't even have any programs which can make use of it in a meaning full way. What is the best way to contact devs in order to re-enable the appropriate use-flag?

In addition to kdelibs you need to patch some other ebuild, like kdebase-runtime-meta, kde-base-startkde and some other.
Unfortunately patching ebuilds is not enough for new installation.
Successful kde installation depends on used stage3 rather than portage ebuilds patching.
Last time devs made some changes on stage3 that prevents applying patches to ebuilds. In fact you can apply patch, but you can't build packages because some additional RDEPEND checking was applied by them.
In particular, some of cmake macros was changes, and now we have additional RDEPENDS checking from cmake. It blocks installing patched ebuilds.
As I noticed, stage3 from August 01st allows to install semantic free kde, but stage3 from August 08th blocks installation with cmake error messages about unsuccessful RDEPENDS checking. cmake macros contains explicit nepomuk-core, nepomuk-widget, akonadi existance checking.
You will be successful with patches, if you updating existing kde installation.
If you installing new system right now, you need an old stage3 tarball, that not yet contains modified cmake macros.

Code:

What is the best way to contact devs in order to re-enable the appropriate use-flag?

I doubt that you will be able to convince them to enable semantic-desktop USE flag. They went too far, that it can be simply return (see about cmake)