layman -d kde-testing; layman -L; layman -a kde;

In other news,

Qt 4.6.0 final was released by Nokia yesterday. You’ll find ebuilds in portage’s ~testing. If you’re using stable and want to try it out, make sure you keyword ALL the ebuilds, or you might get ugly blocks A keyword file is available in qting-edge.

Upgrading world is the recommended way to go to avoid B blocks. If you don’t want to upgrade world, make sure your upgrade command includes all installed Qt modules or you will get blocks.

emerge -av1 $(qlist -IC x11-libs/qt\-)

Remember that “b” (lowercase b) blocks are automatically resolved by portage, just remove --pretend and proceed with the upgrade.

For those wondering, KDE 4 works fine with Qt 4.6

If you’re upgrading Qt from a previous version and your Qt apps misbehave, you should rebuild everything depending on Qt:

emerge -av1 $(for i in $(qlist -IC x11-libs/qt-); do equery -q d $i | grep -v 'x11-libs/qt-' | sed "s/^/=/"; done)

KDE 4.3.4 was also released yesterday, ebuilds are available in portage as usual

Lots of stuff to build, have fun!

Some people are still using it though and they have been asking how they can keep it on their system, without emerge screaming each time they try to update world.

I’m writing this post to guide those people (you? ) on how they can achieve that.

1. Adding the kde-sunset overlay
Perhaps the most important thing you need to remember is that the ebuilds will be completely removed from the tree, so you need to add an overlay called kde-sunset to portage which contains a copy of most of them.

To add the overlay you need to have layman with git USE flag enabled:

USE="git" emerge -av layman

make sure you add the git USE flag in your package.use or make.conf

you can then use layman to install the overlay:

layman -f
layman -a kde-sunset

if this is your first time using layman, you’ll have to add the following line @ the end of your make.conf:

source /usr/local/portage/layman/make.conf

you can keep the overlay updated by running:

layman -s kde-sunset

2. KDE 3.5 is masked (this is necessary only while KDE 3.5 is still in tree)
Now we have the overlay, but until KDE 3.5 is completely wiped off the tree, there’s a mask to warn users about it.
Portage will scream about this mask each time you try to emerge so you need to unmask KDE 3.5 manually.

There are two (and a half) ways to do this:
a1) if your package.unmask is a folder, symlink the unmask file from kde-sunset to /etc/portage/package.unmask/

ln -s /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 /etc/portage/package.unmask/kde-3.5

a2) if your package.unmask is not a folder you can append the file (but you’ll have to update it manually)

cat /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 >> /etc/portage/package.unmask

b) if you don’t like all that, you can emerge autounmask

emerge -av autounmask

and ask it to unmask stuff for you – note that autounmask doesn’t like :slot and will only work with -version

autounmask kde-meta-3.5

3. I don’t want KDE 4 (yet)
So all is great now but portage wants to install KDE 4 when you emerge world.
This is happening because KDE 4 went stable recently and portage thinks you want to upgrade (you should btw ).
To fix this one we need to tell portage that we actually want the 3.5 version of KDE and we don’t care about 4.

we need to edit /var/lib/portage/world and add a version (or a slot) to every kde 3.5 app we have in there.

* be careful with this file *

for example, lets say that you installed kde 3.5 using the kde-meta ebuild.
if you open /var/lib/portage/world you’ll find a line saying

kde-base/kde-meta

you need to add :3.5 which is the 3.5 slot, or -3.5.10 which is the version (or both, version first) at the end. if you add the version, you’ll have to prepend a “=” as well.

the line should now read:

kde-base/kde-meta:3.5

do this for each KDE 3.5 app you have in the world file. If you’re unsure of the slot/version, use eix packagename to find it out.

4. All systems go

emerge -avDuN world

^^ this should now be clean of any KDE 4 traces and mask warnings

If you have any issues or are interested in maintaining kde-sunset, you may visit us over @ #gentoo-kde in freenode’s IRC network or drop us an email at kde _at_ gentoo _dot_ org. We’ll do our best to help you

Maybe after reading this post your KDE 3 installation will last a bit longer

Enjoy and see you w/ KDE 4 soon

We also have KDE 4.3.1 in stable \o/

KDE 3.5 is on its way out of portage, with kde-sunset being the overlay that will (hopefully) be maintained by users still interested in it.

Finally, KDE 4.4 Beta 1 is due December 1st and you’ll find it in the kde-testing overlay as usual

The first bugfix release for KDE 4.3, 4.3.1, is now available.

You can read about the improvements it brings here.

Ebuilds for KDE 4.3.1 are already available in gentoo for architectures amd64 and x86.

To upgrade from 4.3.0 you simply need to

emerge --sync
emerge -avDuN world

This should be a straightforward update for most people.

If you’re upgrading from an older KDE 4 version (or clean-installing KDE 4 on a stable system) you should keyword-unmask KDE 4.3 by following this post’s instructions. You’ll also find some troubleshooting hints there.

The ebuilds are hard.masked for all other architectures due to bug 280312.

As usual, if you have any issues, feel free to leave a comment or visit us @ IRC: freenode/#gentoo-kde

KDE 4.3 has arrived

Lots of behind-the-scenes fixes, a new pretty (debatable) default plasma theme and various new stuff across the board make kde 4.3 an exciting release!

Gentoo ebuilds were available the moment tarballs were released, thanks to the hard work of our Gentoo KDE team

However, since 4.3 brings some new packages (and dependencies), we’ve hard masked the ebuilds until everything gets the proper keywords.
You can follow the keywording progress in bug 280312.

Instructions on how to unmask kde 4.3 after the screenshot

unmasking & installing kde 4.3
kde 4.3 might be masked but it works fine on x86 and amd64 (for other archs check the bug above).
to install it, you can easily unmask it using the unmask file provided in the kde-testing overlay, [kde-testing]/Documentation/package.unmask/kde-4.3

if you don’t have / don’t want the overlay, you can grab the file here.

you can also use a command similar to

# unmasking kde 4.3
wget -O /etc/portage/package.unmask/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.unmask/kde-4.3'

to automatically save the unmask file to your unmask folder (if you use folders)

for those using stable gentoo, there’s a similar keywords file

# adding kde 4.3 in package.keywords/
wget -O /etc/portage/package.keywords/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.keywords/kde-4.3.keywords'

troubleshooting
if you’re trying to upgrade from kde 4.2, but portage gives you nice little blocks, there are a few things you can check:

• make sure you’ve synced the tree and kde-testing overlay (if using it) :p
• make sure the unmask/keyword files are correct and up-to-date
• check that you don’t have any 4.2 versioned kde-base/* items in /var/lib/portage/world
• check that you don’t have any 4.2 versioned sets in /var/lib/portage/world_sets
• emerge -avDuN world — you’ll probably get some messy output but all blocks should be automatically resolved

if you hit any issues feel free to leave a comment, check the gentoo kde 4 guide (should be up-to-date soon) or visit us @ #gentoo-kde (freenode).

enjoy your shiny new kde!

UPDATE: All <qt-*-4.5.3:4 ebuilds were removed on Nov 11th, 2009, so this problem is now fixed

So…… you’re trying to emerge kde 4 on your fresh ~ gentoo installation but strange blocks show up… stuff like

[blocks B ] >x11-libs/qt-opengl-4.5.1-r9999 (">x11-libs/qt-opengl-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-webkit-4.5.1-r9999 (">x11-libs/qt-webkit-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-svg-4.5.1-r9999 (">x11-libs/qt-svg-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-core-4.5.1-r9999 (">x11-libs/qt-core-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-qt3support-4.5.1-r9999 (">x11-libs/qt-qt3support-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ]
[blocks B ] x11-libs/qt-sql-4.5.1-r9999 (">x11-libs/qt-sql-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-script-4.5.1-r9999 (">x11-libs/qt-script-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)
[blocks B ] >x11-libs/qt-test-4.5.1-r9999 (">x11-libs/qt-test-4.5.1-r9999" is blocking x11-libs/qt-gui-4.5.1-r2, x11-libs/qt-dbus-4.5.1)

All this is happening because of recent changes to gentoo’s Qt ebuilds. In Qt Team’s last meeting it was decided to make most USE flags disabled by default, to allow the user to choose which ones he wants to enable, rather than disable.

However, in portage’s current state, the stable Qt packages (4.5.1 version) use the old USE flags with lots of them enabled by default.

Now comes the tricky part. KDE depends on qt-gui with dbus USE flag enabled. Normally, when portage sees that dependency, it checks your USE flags. If dbus is enabled, all is good. If not, it breaks with an error telling you to enable it.

In reality this never happens. Portage first checks qt-gui-4.5.2, which doesn’t have dbus enabled by default. No go. But wait, qt-gui-4.5.1 has it enabled and portage falls back to it. So now portage tries to mix all the other qt-*-4.5.2 packages with qt-gui-4.5.1 (and its 4.5.1 dependencies) and as I’ve mentioned before, this is not allowed.

Boom, blockers.

SOLUTION

Ok maybe you didn’t feel like reading all of the above, so I’ve titled this so you can find it easily

The solution to this problem is suprizingly easy.

Add “dbus” and “qt3support” to your make.conf USE (dbus can also go in package.keywords for qt-gui).

OR

Switch to the Desktop Profile.

Its that easy (thankfully)

WHY DID IT HAVE TO BREAK?

Thats a good question. The real reason this broke is because the stable version has +dbus (which we can’t change now cause its stable – too much hassle) and the testing version has -dbus (which is better since the idea is you get a package and “add” to it with USE flags). Since the Qt Team decided to go through with this change and Portage falls back to the older version without a warning, there’s nothing we can do about this, at least until a new Qt version goes stable with -dbus or portage’s behavior changes.

Thats all folks =] Questions welcome in the comment system below

Now available in Gentoo’s kde-testing overlay, soon in tree as usual!

update: in cvs tree

It’s already available in gentoo’s kde-testing overlay and will be added in portage’s tree really really soon

update: 4.2.3 is now in the portage tree =]

This happened because some applications (namely ark and nepomuk) now depend on a new package in extragear/libs called libknotificationitem.

I’ve made the necessary modifications in gentoo’s kde-testing overlay to fix the issue  by adding a new ebuild for libknotificationitem and adding libknotificationitem DEPEND lines in ark and nepomuk. I also had to revbump plasma-workspace to r1 and block the old ebuild because libknotificationitem had file collisions with it.

So, if you had issues while @live-rebuilding kde4 today, sync your overlay and update

update: libknotificationitem just got moved to kdelibs/experimental

Most of the work is now done. The eclasses have gained EAPI 2 support, tampakrap converted the misc apps to EAPI 2, we killed some eclass bugs that made some kde-base packages fail and @kde-3.5 and other ebuilds like amarok 1.4 build and install fine next to their 4.2 siblings.

A few more tests left before the changes are merged to the tree