| Summary: | kde-base/kactivities-4.13.3-r2 RDEPENDS on KDE5, and kde-plasma/kactivitymanagerd:4 missing | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Navid Zamani <navid.zamani> |
| Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | comrel |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Navid Zamani
2016-07-09 21:04:50 UTC
*** 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. :) |
