Qt 4.7 beta 1 is now available in the qting-edge overlay.

To install it, add the overlay (using layman or PORTDIR_OVERLAY) and unmask qt-4.7_beta1 by copying or linking the keywords file we provide in your /etc/portage/package.unmask/ folder.

ln -s /path/to/qting-edge/Documentation/package.keywords/qt-4.7 /etc/portage/package.unmask/

# IF YOU USE A package.unmask FILE, run the following INSTEAD
cat /path/to/qting-edge/Documentation/package.keywords/qt-4.7 >> /etc/portage/package.unmask


then update your world:

emerge -avDuN world

if you only want to update Qt, run

emerge -av1 $(eix -I --only-names x11-libs/qt-)

Please report any ebuild-related bugs you find in our bugzilla, prefixed with [qting-edge] in the summary!

Enjoy

update #1: upstream accepted my patch, so the next tmux release will provide window-status-alert-{attr,fg,bg} Only difference is the use of alert instead of flagged. It sounds better anyway I’ll adjust my patch on 1.2 as well

update #2 [2010/05/17]: uploaded my updated config file, now using ` as my prefix key

I gave tmux a try yesterday.

Clean config file, thorough documentation and a few nice touches here and there (i.e. better, persistent window splitting) make it a nice alternative to screen, but the biggest difference lies in memory usage. Screen can easily eat up to 40-50mb with just a few windows open, but tmux has yet to reach the 10mb mark!

You may argue that ram is cheap these days, but when you’re on a 360mb VPS ram matters

I did find a few bugs/annoyances, for instance if you add set-option -g default-terminal “screen-256color” in your config file, tmux stops evaluating the #T variable.

I hacked my way out of this one by adding the following in my .bash_profile instead:

[[ $TERM == "screen" ]] && export -p TERM="screen-256color"

Turns out that’s not tmux’s fault but bash’s, I’ll have to create a patch for that as well If you have the same issue, you can use the above hack as a temporary fix.

Also version 1.2 does not provide a way for you to customize the colors used on window titles with alerts (either monitored or when the bell is active), but I patched that and sent it upstream

You can find an ebuild with the patch in my overlay, wirelay (layman -a wirelay ).

The patch was accepted upstream so it’ll be in the next release.

My tmux looks like this:

and with some split panes:

finally, below is my (updated on 2010/05/17) tmux.conf config file, used in the above screenshots.

I decided to use ` as my prefix key, its really better than hitting ctrl-a all the time

# ` is an interesting key for a prefix
set-option -g prefix `
# set-option -g prefix C-a

unbind-key C-b
bind-key C-a last-window
bind-key ` last-window
bind-key a send-prefix

# we might need ` at some point, allow switching
# we can also send the prefix char with `-a
bind-key F11 set-option -g prefix C-a
bind-key F12 set-option -g prefix `

# 0 is too far from `
set -g base-index 1

# set-option -g default-terminal "screen-256color"
set-option -g mouse-select-pane on
set-option -g status-keys vi
set-option -g bell-action any
set-option -g set-titles on
set-option -g set-titles-string '#H:#S.#I.#P #W #T' # window number,program name,active (or not)
set-option -g visual-bell on

setw -g mode-keys vi
setw -g mode-mouse on
setw -g monitor-activity on

bind e previous-window
bind f next-window
bind j up-pane
bind k down-pane

set-option -g status-utf8 on
# set-option -g status-justify centre
set-option -g status-justify left
set-option -g status-bg black
set-option -g status-fg white
set-option -g status-left-length 40

set-option -g pane-active-border-fg green
set-option -g pane-active-border-bg black
set-option -g pane-border-fg white
set-option -g pane-border-bg black

set-option -g message-fg black
set-option -g message-bg green

#setw -g mode-bg black

setw -g window-status-bg black
setw -g window-status-current-fg green
setw -g window-status-alert-attr default
setw -g window-status-alert-fg yellow

set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'

# set -g status-right '#[fg=green]][#[fg=white] #T #[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'
set -g status-right '#[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

set -g history-limit 4096

# `+r reloads the configuration, handy
bind r source-file ~/.tmux.conf

Do you need to filter spam email on your IMAP account, but can’t do it on the email server and your client software (mutt? ) won’t provide that capability?

meet IMAP Spam Begone

a nifty python script that uses spamassassin to remotely mark (and optionally move/delete) spam mail over IMAP.
it can also use spam/ham folders to teach your spamassassin

Available in gentoo:
[*] mail-filter/isbg
Available versions: (~)0.99-r1
Homepage: http://redmine.ookook.fr/projects/isbg
Description: IMAP Spam Begone: a script that makes it easy to scan an IMAP inbox for spam using SpamAssassin

usage instructions here: http://redmine.ookook.fr/projects/isbg/wiki#SpamAssassin

some example commands I’m using:

# to check for spam:
isbg.py --imaphost [HOST] --imapuser [EMAIL] --delete --noreport --spamc
# to teach spamassassin:
isbg.py --imaphost [HOST] --imapuser [EMAIL] --noreport --teachonly --learnspambox INBOX.spam --learnhambox INBOX.read-mail --spamc


For the last few days, linuxized.com has been enjoying its new home, a linode.com VPS. Running Gentoo. Of-course

A 24/7 remote box had been on my wish-list for some time and my shared-hosting 1-year contract was ending, when I discovered linode.com.

They give you a VPS and let you do anything you want with it. They also provide you with a control panel that lets you tweak pretty much everything.

So I bought the cheapest one (360), created some partitions and booted it using a bootable image they provide (something similar to systemrescuecd).

I then downloaded the latest stage3, configured the base system and booted it using a kernel provided by linode.

Instead of compiling anything on the VPS, I decided to use binary packages to speed things up.

I have a bunch of chroots on my home box, one of them being stable-x-less. I cloned it, adjusted the use flags a bit and rsync’d all the binpackages to the VPS.

Now everything works great and I have a bunch of services running (http,email,znc,nagios,etc)

Linode++ for the excellent service they provide

This year’s FOSDEM is just around the corner! (February 6th/7th, Brussels, Belgium)

A lot of interesting talks and presentations will take place and I’m pretty sure there’s going to be a lot of beer too! ^_^

Many Gentoo Developers will be there for the whole weekend, including me

See you all there

update 2009-11-07: fixed bug in script

uzbl has a simple but nice formfiller script that automatically fills forms for you.

if you’ve been using firefox’s password manager, you probably have a large list of user details you’d probably like to use in uzbl too. migrating the data is actually simpler than you think.

first, install the Password Exporter add-on in your firefox.

then go to edit->preferences->security->import/export passwords, click export passwords (do NOT check the checkbox), select csv in the bottom right select box and save the file in your ${HOME}.

you should now have a file called password-export-`date +%Y-%m-%d` (current date ) in your ~ folder.

now open a terminal and run the following:

cat ~/password-export-`date +%Y-%m-%d` | grep "^\"http" | while read i; do S=`echo $i | cut -d"\"" -f2`; S="${S/http:\/\/}"; S="${S/https:\/\/}"; U=`echo $i | cut -d"\"" -f4`; P=`echo $i | cut -d"\"" -f6`; UF=`echo $i | cut -d"\"" -f12`; PF=`echo $i | cut -d"\"" -f14`; echo $UF: $U | sed "s/\@/\\\@/g" > ~/.local/share/uzbl/forms/$S; echo $PF: $P | sed "s/\@/\\\@/g" >> ~/.local/share/uzbl/forms/$S; done

note that the above command will overwrite any existing domains.
the command below are slightly modified to only add non-existing domains:

cat ~/password-export-`date +%Y-%m-%d` | grep "^\"http" | while read i; do S=`echo $i | cut -d"\"" -f2`; S="${S/http:\/\/}"; S="${S/https:\/\/}"; U=`echo $i | cut -d"\"" -f4`; P=`echo $i | cut -d"\"" -f6`; UF=`echo $i | cut -d"\"" -f12`; PF=`echo $i | cut -d"\"" -f14`; echo $UF: $U | sed "s/\@/\\\@/g" >> ~/.local/share/uzbl/forms/$S; [[ ! -f ~/.local/share/uzbl/forms/$S ]] && echo $PF: $P | sed "s/\@/\\\@/g" >> ~/.local/share/uzbl/forms/$S; done

that’s it! you should have a file per domain with the necessary info in ~/.local/share/uzbl/forms

ls ~/.local/share/uzbl/forms/

open a uzbl instance, visit a site with a form and press zl [default binding] to tell formfiller to fill in the form for you

I’ve been using firefox for too long.

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.

Today we renamed kde-testing back to kde in layman. You should remove and add the overlay again:

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!

So… qt-*-4.6.0_rc1 is now in the portage tree, masked (since its not a final release) and you can begin testing your shiny Qt applications with it.

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/

As most of you know, KDE 3.5 is getting off the Gentoo train for various reasons mentioned elsewhere (in short: security, lack of upstream interest).

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