Hi, somehow after bug #563502 was closed, this got messed up again. 1. I have a KDE 4 desktop, and obviously have no interest in moving to KDE 5 / “Plasma 5“ and enjoy even more bugs and missing features. ^^ It takes at least a few years for that to become acceptable. 2. So I’ve not moved to any [plasma] profile. 3. I have also masked [kde-*/*:5], so the cancer doesn’t creep in. 4. Curiously, kde-base/kactivities-4.13.3-r2:4 *is already installed*, but did not depend on anything KDE5 back then, as nothing KDE5 is installed on my system, and nothing got removed. [+] So I should be able to expect everything to stay on KDE 4, and not ever install KDE 5, right? [−] But now [kde-base/kactivities-4.13.3-r2:4] suddenly [RDEPEND]s specifically on [kde-plasma/kactivitymanagerd:5]. ––> That should obviously never be. I suggest putting things back to how they were when I updated about a week ago, where the exact same package and version was still happy without depending on anything KDE5.
*** This bug has been marked as a duplicate of bug 563502 ***
(In reply to Johannes Huber from comment #1) > > *** This bug has been marked as a duplicate of bug 563502 *** Did you even read this bug? This is *specifically* not a duplicate, unless you plan to re-open and re-purpose the other bug. This bug is about -r2. The other one is about -r1. And in-between, -r2 *USED TO WORK*. NOW IT DOESN’T. AGAIN. 1> It did not work with -r1. 2> It worked with -r2. 3> Now it does not work with -r2 too. Are you planning to leave in faulty? I cannot make this any clearer.
You have masked ebuilds locally this wont work.
(In reply to Johannes Huber from comment #3) > You have masked ebuilds locally this wont work. Please, how can I make you actually read the whole comment #1? KDE 4 ≠ kde-*/*:5
Having pure KDE 4 is no longer supported, but you can have KDE 4 with small number of packages from KDE 5. You need to unmask kde-frameworks/* and kde-plasma/kactivitymanagerd (and some other packages not related to this bug about kde-base/kactivities).
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > Having pure KDE 4 is no longer supported, Then why is this exact package, as I said twice already, currently installed without and kde5 dependencies? This shows that it isn’t necessary. (Hmm, why does it want to re-install it anyway? Because the ebuild changed an now depends on kde5 for provably no reason?)
Anyway, what is the point of having kde4 packages depend on kde5 at all anyway? The user specifically demanded no kde5. Kde5 was not required for kde4 ever until apparently magically now. If some crazy person changed kde4 branch code to actually required kde5 stuff, then that version and any version after that should just be masked and not introduced to a non-kde5/plasma profile in the first place. (Or preferably, that person be ejected from the group, and banned from the version management server.)
(In reply to Navid Zamani from comment #7) > then that version and any > version after that should just be masked and not introduced to a > non-kde5/plasma profile in the first place. Of course this case here is truly nutjob-crazy, because it isn’t even a new version. It is literally the exact same version. Hence it cannot possibly not work without kde5.
Hi Navid, KDE SC 4 and Plasma 4 are no longer supported upstream and while we have kept them both for in Gentoo for some time beyond this, we can't realistically support support this old stuff forever and recently decided to clean up 4.14.3 where possible. kactivities comes in two flavours (kdelibs4 and kf5-based) and consists of two parts - the library (which is coinstallable) and the daemon (which is not). kactivitymanagerd:5 is backwards compatible with kactivities:4, and as a result of the recent cleanup, is the only daemon in the tree. If you intend to remain with KDE 4 long-term, you might consider using the kde-sunset overlay. While unsupported, we are copying obsolete packages / versions there for those that still wish to use them. Finally, I understand you are frustrated but your courtesy whilst using bugzilla is appreciated.
(In reply to Michael Palimaka (kensington) from comment #9) Hello Michael, [finally an actual explanation. That’s all I wanted. Thank you for being sensible. KDE is a troubled beast, due to always jumping on something new, before the old one is even close to good enough for anyone who actually uses the many features it says it provides. I don’t blame anyone from Gentoo for this. I wouldn’t even be in this situation, if there were other “desktop” choices that aren’t obsessed with minimalism but focus on emergence and power.] Yes, my view is, that [eselect profile]s that aren’t […/plasma] ones, should stay with the [kdelibs4] flavor, since I imply that that’s what those profiles mean. Since otherwise why keep two separate KDE profiles at all? (Or did you plan to remove the old one soon?) I will try kde-sunset. Or just unmerge anything KDE that is not an application that I like, and move to something non-“desktop“. What a sad situation…
(In reply to Michael Palimaka (kensington) from comment #9) So… 1. kde-sunset is not in layman anymore… apparently due to lack of maintenance. I had to manually pull it, and make a file in /etc/portage/repos.conf/. 2. egencache reports many errors. 3. kactivities is not is kde-sunset.
(In reply to Navid Zamani from comment #11) > 1. kde-sunset is not in layman anymore… apparently due to lack of > maintenance. > I had to manually pull it, and make a file in /etc/portage/repos.conf/. Unfortunately yes it was expelled from layman as it does not have an "official maintainer". It's not as hard to add manually these days with repo > 2. egencache reports many errors. In KDE3 stuff I guess, due to packages getting moved between categories in main tree. On occasion I've been sent kde-sunset patches which I've applied, but in general that overlay sees no active maintenance. > 3. kactivities is not is kde-sunset. Looks like this was forgotten, I've pushed kactivities:4 and kactivitymanagerd:4 there now.
For anyone with the same problem: It requires two steps to solve: 1. Have the old ebuild in your overlay. 2. For any kde5 packages that ebuild wants to emerge anyway, you need an old version in your overlay as well! This is how I solved it, in this specific case: I googled the following names: kactivities-4.13.3-r2.ebuild kactivitymanagerd-4.13.3-r1.ebuild kdebase-startkde-4.11.22-r1.ebuild , made sure they’re the old ones, put them in my overlay, ran egencache --jobs="$(nproc)" --repo="$YOUR_OVERLAY" --update --update-use-local-desc eix-update on it (just so the search still matches what’s available and you later can’t get confused), and *kept everything KDE 5 masked* by leaving kde-*/*:5 in /etc/portage/package.mask/cancer, and the qt5 use flag not enabled. Then I just started the update process as normally. :)
I bumped into that bug today , the issue is introduced by change 6da1ba829e1e240c7c4fe467a22d23d275368154 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6da1ba82 kde-base/kactivities-4.13.3-r2 now depends on kde-plasma/kactivitymanagerd:5 which messes up completely the upgrades, reverting the change fixes the builds. In other words restoring to old ebuilds helps: kactivities-4.13.3-r2.ebuild kactivitymanagerd-4.13.3-r1.ebuild
(In reply to mike from comment #14) > the issue is introduced by change > > 6da1ba829e1e240c7c4fe467a22d23d275368154 Is there a semi-automatable algorithm to finding the correct change? I want to make a script to fill an overlay. I’d like to make a kde4-only overlay. > In other words restoring to old ebuilds helps: Well, that’s what my instructions right below already said. :)
