KDE 4.5.0 in Gentoo

The Gentoo KDE Team decided not to include KDE 4.5.0 in the main portage tree, due to the lack of the KDEPIM suite, which would cause a lot of trouble to users trying to upgrade. Thus, it will remain in the kde overlay hardmasked. It can be installed with KDEPIM 4.4.5 though, if the user adjusts the keyword files accordingly. The first KDE 4.5.X version that will include the KDEPIM suite will be added to portage as well.

Furthermore, we decided to keep a bit more the live ebuilds of the 4.4 branch, and not to provide any snapshots yet. The Gentoo KDE Guide has been updated to adjust those decisions.

EDIT: Also take a look at comment 10, which has a better explanation

EDIT 2: For news regarding KDE 4.5 in Gentoo, please read http://blog.tampakrap.gr/gentoo-kde-and-qt-september-meetings/

=-=-=-=-=
Powered by Blogilo

17 Responses to KDE 4.5.0 in Gentoo

  1. cael says:

    Hi
    What’s the problem with kdepim? Is kdepim not included in the official 4.5 SC?

    Reply
  2. baaann says:

    Can it not be added to the tree with just KDEPIM hardmasked to only allow 4.4.5 to be installed?

    Reply
  3. Faisal says:

    baaann is right.

    The whole KDE desktop is withheld because of a package. It is not even a dependency package. Please look into this again and prioritize accordingly to the majority’s wishes not to minority’s wishes.

    Reply
  4. Duncan says:

    Interesting.

    @ cael: Correct. kmail is in the middle of a transfer to akonadi, and while it’s sort of ready, the kdepim folks decided not to repeat the mistakes of the not-too-distant kde past and release without KNOWING it’s ready, including proper testing, etc. So they skipped a 4.5.0 full release version, and are scheduled for a 4.5.1 release a month from now. For those willing to test, there is however a release candidate available, that would have been 4.5.0 had they decided to go that way.

    Back to 4.5.0. As I said, interesting. I have the overlay in layman and upgraded to 4.5.0 I believe the day after official release, without issue, including no issue with kmail, which is still 4.4.5, which I definitely use. Of course I run ~arch (~amd64 on the main machine, ~x86 on the early atom based netbook), always update deep newuse and do a revdep-rebuild and depclean afterward, plus I’m already running gcc 4.5.1 as well, so everything’s always on latest available ~arch or newer and the system is kept reasonably self-consistent. (I’ve also been running LDFLAGS with –as-needed for quite some time, it’s not a new thing here.) I expect people who have a stable base system, only keywording specific packages, and who aren’t quite as meticulous about keeping a clean system, will experience more problems than I did.

    But when I upgraded, 4.5.0 was in the overlay, ~arch naturally, but not hard masked. The only packages in my unmask files are >=portage-2.2_pre and =gcc-4.5*. The only packages in my keywords files are gcc, binutils, lib_users, and pan (live version from my personal overlay), all keyworded **.

    Given this blog entry, I guess that means next time I update, 4.5.0 will be hard masked, and I’ll have to add a kde.unmask file with hundreds of entries, to keep from downgrading. =:^( Oh, well… It’s not like I’m not used to such things, running as close to upstream releases as I do.

    BTW, based on my experience so far, all the blurbs about 4.5.0 being faster and more stable and bug-free than previous versions are definitely true! In fact, one bug that had been freezing the entire computer (not even the magic-SRQ SUB sequence works, total lockup) after about 24 hours in X, apparently an X/graphics based lockup, that I had attributed to the fact that the freedomware Radeon r7xx (hd4650) graphics drivers I’m running weren’t quite stable yet, has apparently up and disappeared, as I last rebooted on the 10th, and have been in X since I restarted kde after the upgrade (now 48 hours or so, IIRC), with no lockups! It may have been an X/KMS/kernel based graphics bug, but apparently, kde 4.4.x was tickling it, and 4.5.0 doesn’t seem to. =:^)

    So I’m a very happy camper ATM, kde-4.5.0 with kmail 4.4.5 and all! I must admit that I’ve been a bit leary about the coming kmail transition to akonadi and I’m not sure it’s going to be painless, but the fact that the kdepim folks /did/ decide to wait that extra month and go with 4.5.1 instead of 4.5.0, is a very good signal, quite wonderfully different from the “release a full version and let the users deal with the fallout of our lack of readiness” that early kde4 was so rightly infamous for. Perhaps kde has learned that lesson. But regardless of what that change with 4.5.1 brings, I’m pretty happy with 4.5.0 and the kdepim 4.4.5 components I’m running right now! This is honestly the first kde4 version I can recommend without reservation! 4.4 was almost there, but 4.5.0 IS there, at least for me! =:^)

    Reply
  5. baaann says:

    @Duncan
    Good to hear a positive review.
    I believe the blog is only referring to KDEPIM being hardmasked, not the entire kde overlay?

    @Faisal
    Thanks for the support, however it is better that the devs release updates to the portage tree that they are happy they can support, rather than prioritise the majority’s wishes. I just didn’t understand why it could not be updated with the problem app hardmasked

    Reply
  6. cael says:

    @Duncan
    Thanks for your answer! I’ll use the overlay to upgrade to 4.5 (I recently replaced kmail with thunderbird so it shouldn’t be any kdepim problem).

    Reply
  7. cael says:

    The kde 4.5 decision gets discussed quite heavy on some news pages. There’s an article on the german linux page (pro-linux.de) bashing at gentoo kde team for their decision to not include kde 4.5 in portage. They especially blame the team for their misinformation in this case and asking themselves why gentoo simply don’t use kdepim 4.4.5 in combination with kde 4.5 like other distributions.

    This is NOT my opinion! It’s just some information about this case.

    Reply
  8. tampakrap says:

    First of all, KDEPIM 4.5.0 is not hardmasked, it is not problematic, it simply doesn’t exist. This fact itself arose the issue if we should officially support a release that is not fully complete in our opinion.
    KDE 4.5.0 packages are available to overlay, for anyone who wishes to update/test/whatever. We didn’t say we’ll skip the whole 4.5 suite from the tree, we decided to skip only the versions that lack the KDEPIM suite. It’s the KDEPIM guys that wanted to skip their release for now, and we want to bring only fully working versions to tree.
    Personally, I support the KDEPIM guys’ decision to skip it for now, since it is not ready, and I don’t find it too important for someone to wait a month to get a fully working KDE.
    Finally, I’d like to remind you all that you are able to do the 4.5.0 4.4.5 combination if you just adjust your keywords files. The nature of Gentoo doesn’t allow the developers’ side to do it. We can only point you on how to do it, and in fact I did document it in the installation guide in large detail.
    P.S. Of course we’ll be happy to help you for any problem you may have in your upgrade/installation, as usual we can be found in freenode #gentoo-kde, in gentoo-desktop mailing list or in gentoo bugzilla.

    Reply
  9. sebas says:

    It’s perfectly fine, tested and supported to use KDE PIM from 4.4.5 together with kdelibs from 4.5.x, many developers are even running that, and it’s how it should be shipped. There’s no reason not to ship other KDE products (such as the Plasma Desktop, or updated apps), it’s a mere release engineering artifact that we didn’t include new PIM packages in the release, KDE’s source and binary compatibility policies are in place to prevent that from happening anyway.

    The migration to the Akonadi-based KDE PIM will happen as we deem it stable enough. This, as others point out is to shield users from productivity loss due to issues in Kontact or any of its components. The KDE PIM developers are both actively supporting PIM from 4.4, and in parallel are making the Akonadi-based KDE PIM release-ready.

    Now there seems to be the miscommunication that there’s no stable PIM to use right now, and that’s wrong. We recommend shipping 4.4′s PIM with 4.5 as well.

    Disclaimer: I work on KDE and have worked with the KDE PIM team on release scheduling.

    Reply
  10. reavertm says:

    Lack of kdepim-4.5.0 is NOT the reason why we skipped KDE SC 4.5.0 in Gentoo.
    There reason are not addressed regressions we consider significant enugh:

    https://bugs.kde.org/show_bug.cgi?id=230247 (minor but annoyance and regression)
    or
    https://bugs.kde.org/show_bug.cgi?id=245491 (like above)
    and
    https://bugs.kde.org/show_bug.cgi?id=243991 (this will be fun-breaker for many)

    There are also plasma system tray glitches (not addressed yet), plasma folderview bug 247144, dolphin tooltips bug (bug 245491, fixed in 4.5.1), KTar tmpfile regression (fixed in 4.5.1).

    Releasing it with known bugs would only cause duplicates on bugs.kde.org. We tend to care for user experience and wait for major regressions to be fixed (there is a question why they’re being introduced in first place).

    Reply
  11. sebas says:

    230247 confuses me, that’s apparently from 4.4.x. If you’re shipping that already, and you don’t want to ship unrelated software because of a bug in something you’re already shipping, that’s … strange.

    Anyway, the inital blog was way confusing in that it talked about completely different issues. This kind of communication mishaps can happen.

    Reply
  12. reavertm says:

    @sebas

    Nothing strange here – kdepimlibs-4.5 requires ~akonadi-1.4 – and even when this bug was introduced earlier – it definitely didn’t happen for me when I was using and testing 4.4 during its lifetime – so from my observation (kdepim packaged Gentoo way – so with dependencies set by myself) it’s actually regression in 4.5, so not a bug in something we’re shipping already.

    And we ship kdepimlibs-4.5 with KDE SC 4.5 (to work with kdepim 4.4) because it’s what KDEPIM devs support – your suggestion would be to ship kdepimlibs-4.4? (with previous stable akonadi – from 1.3 series?). This is apparently unsupported – for Plasma workspace akonadi dataengine claims to require KdepimLibs 4.4.60.

    Reply
  13. Patrizio says:

    @reavertm Today they released 4.5.1 with several bugfixes

    up to their roadmap none of 4.5.x will have kmail/kdepim.
    we must wait for 4.6

    so i ask, why not adding 4.5.1 too as users are free to use 4.4 kdepim too?

    thanks

    Reply
  14. tampakrap says:

    @Patrizio:
    we are going to have a meeting in two days, and we’ll decide about the future of KDE 4.5.1 and the beta kdepim releases

    Reply
  15. Patrizio says:

    @tampakrap this is good for me as it looks not like a closed door.

    Can you please update us when you have any news? (is this blog indexed in gentoo planet?)

    thank you all

    Reply
  16. tampakrap says:

    yes it is, i’ll add the summary of the meeting on a new blog post

    Reply
  17. Pingback: Sabayon KDE 4.5.x ? | What's Going On?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>