Its excellent vimperator extension has prevented me from switching to anything else, but it is beginning to show its age. Slow loading times, occasional crashes, horrible JS performance…

Meet uzbl. Wordplay for usable. Its developers describe it as web interface tools which adhere to the unix philosophy. I like to think of it as a terminal for the web.

I have valid reasons: Instead of using tabs, I just spawn uzbl windows whenever I need something, then close them. Same as a terminal. That is possible because it loads instantly – like a terminal! Add the fully customizable vim-like bindings and very good webkit engine and you have a winner!

The fact that I’m using awesome (a tiling wm) also helps, since it manages all the windows for me.

Since I like uzbl so much, I added it to the portage tree:

[I] www-client/uzbl
Available versions: (~)0_pre20091130{tbz2} **9999{tbz2} {helpers}
Installed versions: 0_pre20091130{tbz2}(04:03:14 PM 12/04/2009)(helpers)
Homepage: http://www.uzbl.org
Description: A keyboard controlled (modal vim-like bindings, or with modifierkeys) browser based on Webkit

One tagged release and a live ebuild (that uses either the master or experimental branch).

I’ve also patched dmenu with the vertical patch to make it useful with uzbl. You can find the updated ebuild in wirelay (layman -a wirelay) – at least until I get the dmenu maintainers to add the patch in portage.

But there’s a catch.

4.6.0_rc1 is not binary compatible with 4.6.0_beta1. [1]
This means that if you’re upgrading from 4.6.0_beta1 you have to rebuild every single app depending on qt-*, or they won’t start at all. This obviously includes all of KDE 4.

You can get portage to do that by using a command like this:
*update* it seems some shells didn’t like the old command, so I’ve updated it:

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

Note that this command assumes your system is up-to-date. If some installed packages don’t have ebuilds available for their version anymore, you’ll have to resolve that manually (probably by removing them and rerunning the command).

You’ll find equery in app-portage/gentoolkit and qlist in app-portage/portage-utils.

You don’t need to do this if you’re upgrading from Qt 4.5.3 (although you should). You’ll also be safe if you upgrade from 4.5.3 to 4.6.0 final when the time comes.

Portage will warn you about this when you upgrade qt-core to 4.6.0_rc1:

* Messages for package x11-libs/qt-core-4.6.0_rc1:

*
* Binary compatibility broke between 4.6.0_beta1 and 4.6.0_rc1.
* If you are upgrading from 4.6.0_beta1, you’ll have to
* re-emerge everything that depends on Qt.
* Use the following command:
*
* emerge -av1 $(for pkg in $(equery -q d \
* $(qlist -IC x11-libs/qt-) | grep -v “x11-libs/qt-” |
* sort -u); do echo “=$pkg”; done)
*
* YOU’VE BEEN WARNED
*

But users (my user side as well :p) tend to ignore ewarns from time to time

Happy rebuilding!

[1] http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against-previous-46/

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

[blocks B     ]  >x11-libs/qt-gui-4.4.2-r9999 (“>x11-libs/qt-gui-4.4.2-r9999″ is blocking x11-libs/qt-xmlpatterns-4.4.2, x11-libs/qt-script-4.4.2,
x11-libs/qt-dbus-4.4.2, x11-libs/qt-sql-4.4.2-r1, x11-libs/qt-qt3support-4.4.2, x11-libs/qt-svg-4.4.2, x11-libs/qt-test-4.4.2, x11-libs/qt-opengl-4.4.2,
x11-libs/qt-core-4.4.2-r2)

[blocks B     ]    <x11-libs/qt-gui-4.5.1 (“<x11-libs/qt-gui-4.5.1″ is blocking x11-libs/qt-opengl-4.5.1, x11-libs/qt-svg-4.5.1-r1, x11-libs/qt-script-4.5.1,
x11-libs/qt-dbus-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-test-4.5.1, x11-libs/qt-qt3support-4.5.1, x11-libs/qt-sql-4.5.1, x11-libs/qt-core-4.5.1)

this means that new Qt libraries are available and portage is trying to upgrade only *a part* of the ones you have installed.

this is bad because mixed versions of Qt packages (like qt-core-4.5.1 alongside qt-svg-4.4.2) can result in unexpected breakage.

unfortunately, at the moment this error is the only way we can prevent version mixing.

to get past the error, you can:

• emerge -avDuN world
  • updating world tells portage to upgrade all Qt packages in one run
• emerge -av1 `eix -I --only-names x11-libs/qt-`
  • if you don’t want to upgrade everything, you can use this command to upgrade all the installed Qt libraries

if you still have problems, don’t hesitate to comment and I’ll do my best to help

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 means that if, for example, you’re using the “kde-testing” overlay, you’ll have to manually tell portage to use any updated eclasses available in the overlay. If you don’t, you might end up with broken packages, depending on the overlay. You should check out the overlay’s guides and/or chat with the developers to find out if overriding is necessary/optional.

To tell portage to use the kde-testing overlay’s eclasses [if any], create the file:
/etc/portage/repos.conf

with the following content:

[gentoo]
eclass-overrides = kde

We’re using “kde” instead of “kde-testing”, because that’s the actual overlay name (found in OVERLAY_FOLDER/profiles/repo_name)

For more information on this issue, read gentoo bug #265747

For those not familiar with overlays, they are something like a “repository”. They allow you to add and use ebuilds out of the official portage tree.

In my overlay, called “wirelay”, I usually add fixes from bugs.gentoo.org that I need which haven’t reached the tree yet (and maybe never will). I also keep ebuilds of the latest nvidia drivers and other stuff

To browse the overlay, visit http://github.com/wired/wirelay/tree/master

To add the overlay, install layman ( emerge -av layman ) then run:

layman -f -o http://github.com/wired/wirelay/raw/master/Documentation/wirelay.list -a wirelay

=]