Tag: overlay

Deprecating and banning old EAPIs

Since portage version 2.1.12.2 (and 2.2.0_alpha177) there are two new options for the repository configuration to make repoman aware which EAPIs are deprecated and which are completely banned (bug #470670).

The two configuration keys are eapis-deprecated and eapis-banned in layout.conf. The value for both keys is a space seperated list of selected EAPI numbers. This can be used in any portage ebuild repository, it works in a overlay and in the main portage tree as well.

Lets assume you have an overlay and want to get rid of all old EAPIs with the goal to make the life for contributors easier to know only the latest and not the whole EAPI history. This means you have to mark all as deprecated except the latest.

$overlay/metadata/layout.conf:

# indicate that ebuilds with the specified EAPIs are deprecated
eapis-deprecated = 0 1 2 3 4

And then let repoman in the overlay root directory run to check which ebuilds using old EAPI. 

$overlay repoman full -d

In case repoman find relevant ebuilds, he will be print the ebuild names with the EAPI version as warning. Now comes the fun part, you can start to migrate your ebuilds to latest EAPI. And whenever you have killed a deprecated EAPI, move it from deprecated to banned in the configuration. This means repoman won’t allow you to commit those to the repo anymore. In this example we get rid of EAPI 0.

$overlay/metadata/layout.conf:

# indicate that ebuilds with the specified EAPIs are banned
eapis-banned = 0
# indicate that ebuilds with the specified EAPIs are deprecated
eapis-deprecated = 1 2 3 4

The current configuration for the main portage tree is that no EAPI is banned and EAPI 1 + 2 is deprecated. Since the last weekend in kde overlay all ebuilds are migrated to latest EAPI (5) and older are banned (0-4). Migration was quite easy, because we had just some ebuilds left with EAPI 4. Thanks to the portage team for this nice feature.

Have fun!

Gentoo’s road to Wayland in KDE

KWin in KDE SC 4.11 will include experimental support for Wayland, as you can read in the official 4.11 Beta 1 announcement:

KWin and Path to Wayland—Intial experimental support for Wayland was added to KWin. KWin also got many OpenGL improvements including support being added for creating an OpenGL 3.1 core context and robustness from using the new functionality provided by the GL_ARB_robustness extension. Numerous KWin optimizations are aimed at reducing CPU and memory overhead in the OpenGL backend. Some desktop effects have been re-written in JavaScript to ease maintenance.

As the Beta 1 is already available in the gentoo kde overlay you may ask what the current state is. You are right it is time to talk about it. I will try to serve you the facts.

Current state

Wayland is already packaged in portage (dev-libs/wayland), thanks to the x11 herd.

johu@elia ~ $ eix -s wayland
[I] dev-libs/wayland
     Available versions:  (~)0.95.0 (~)1.0.6 (~)1.1.0 {doc static-libs}
     Installed versions:  1.1.0(21:54:08 05.06.2013)(-doc -static-libs)
     Homepage:            http://wayland.freedesktop.org/
     Description:         Wayland protocol libraries

KWin 4.11 Beta 1 + KWin master (4.8.10 + 9999 ) has already a build option (USE flag) for wayland.

johu@elia ~ $ eix -s kwin
[I] kde-base/kwin
     Available versions:  (4) 4.10.3 (~)4.10.4 **4.10.49.9999^m[1] [M](~)4.10.80^m[1] (**)9999^m[1]
       {aqua debug gles opengl wayland}
     Installed versions:  9999(4)^m[1](22:14:15 18.06.2013)(gles opengl wayland -aqua -debug)
     Homepage:            http://www.kde.org/
     Description:         KDE window manager

It builds and links already successfully against it.

johu@elia ~ $ scan kwin
dev-libs/wayland-1.1.0
dev-qt/qtcore-4.8.4-r5
dev-qt/qtdbus-4.8.4
dev-qt/qtdeclarative-4.8.4
dev-qt/qtgui-4.8.4-r1
dev-qt/qtscript-4.8.4
kde-base/kactivities-9999
kde-base/kdelibs-9999
kde-base/kwin-9999
kde-base/libkworkspace-9999
kde-base/liboxygenstyle-9999
media-libs/mesa-9.1.3
sys-devel/gcc-4.7.3
sys-libs/glibc-2.17
x11-libs/libICE-1.0.8-r1
x11-libs/libSM-1.2.1-r1
x11-libs/libX11-1.6.0
x11-libs/libxcb-1.9.1
x11-libs/libXcursor-1.1.13-r1
x11-libs/libXdamage-1.1.4-r1
x11-libs/libXext-1.3.2
x11-libs/libXrandr-1.4.1
x11-libs/libXxf86vm-1.1.3
x11-libs/xcb-util-image-0.3.9
x11-libs/xcb-util-keysyms-0.3.9
x11-libs/xcb-util-wm-0.3.9

The USE flag is globally masked for stable systems. As a side note, i realy like the stable use mask feature in EAPI 5.

Next steps

1) We need to package the Wayland compositor aka Weston in portage tree, to start a full blown Wayland session.  This task is already in progress (bug #445736), an ebuild is available in the gentoo x11 overlay. Will be finished soon hopefully.

2) Add a wayland build option (USE flag) for the KDE start script (kde-base/startkde). The USE flag will allow us to ship a modified version of it, so that we can tell KWin to use weston/wayland when starting.

So I am realy sure you will be able to play around with Wayland in starting August when KDE SC 4.11.0 is released and hit the portage tree by simply enabling a USE flag. Are you excited? You should!

Have fun!

Disabling semantic-desktop at runtime

Today we bumped  KDE SC 4.11 beta 1 (4.10.80) in the gentoo kde overlay. The semantic-desktop use flag is dropped in >=kde-base/4.10.80, as you may already noticed or read in dilfridges blog post. So if your hardware is not powerful enough or you just don’t want to use the feature you can easily disable it at runtime.

1. Go to the “System Settings” and search for “Desktop Search”

System Settings

 

2. Uncheck at least the file and email indexer. You can also disable the “Nepomuk Semantic Desktop”.

Desktop Search Settings

Have fun!

 

Update

If you want to disable Akonadi you can check out this blog post.

 

CMake picks always the latest boost.

As known as #335108. This is (was) a long term bug in Gentoo KDE scope. The problem is that if you have two or more different boost versions installed, the latest version will be used at build time, regardless which version is (e)selected. Real world example we have boost  1.46.1 and 1.47.0 installed selected the 1.46 slot, the 1.47 slot would be used at build:

$ eselect boost list
Available boost versions:
 [1]   boost-1.46/default *
 [2]   boost-1.47/default

Last night i patched dev-util/cmake-2.8.6 successfully and made the revision bump today in the kde-overlay. So please test =dev-util/cmake-2.8.6-r5, in the case your maintained package is cmake based and needs dev-util/boost at build time. You should test at least with two different boost versions and of course switch between those to check that the selected version is used.

I bumped dev-util/cmake-2.8.7 in the overlay too. The patch is also included in this version.

Start your engines…