Tasty calamares in Gentoo

First of all it’s nothing to eat. So what is it then? This is the introduction by upstream:

Calamares is an installer framework. By design it is very customizable, in order to satisfy a wide variety of needs and use cases. Calamares aims to be easy, usable, beautiful, pragmatic, inclusive and distribution-agnostic. Calamares includes an advanced partitioning feature, with support for both manual and automated partitioning operations. It is the first installer with an automated “Replace Partition” option, which makes it easy to reuse a partition over and over for distribution testing. Got a Linux distribution but no system installer? Grab Calamares, mix and match any number of Calamares modules (or write your own in Python or C++), throw together some branding, package it up and you are ready to ship!

I have just added newest release version (1.1.2) to the tree and in my dev overlay a live version (9999). The underlaying technology stack is mainly Qt5, KDE Frameworks, Python3, YAML and systemd. It’s picked up and of course in evaluation process by several Linux distributions.

You may asking why i have added it to Gentoo then where we have OpenRC as default init system?! You are right at the moment it is not very useful for Gentoo. But for example Sabayon as a downstream of us will (maybe) use it for the next releases, so in the first place it is just a service for our downstreams.

The second reason, there is a discussion on gentoo-dev mailing list at the moment to reboot the Gentoo installer. Instead of creating yet another installer implementation, we have two potential ways to pick it up, which are not mutual exclusive:

1. Write modules to make it work with sysvinit aka OpenRC
2. Solve Bug #482702 – Provide alternative stage3 tarballs using sys-apps/systemd

Have fun!

[1] https://calamares.io/about/
[2] johu dev overlay
[3] gentoo-dev ml – Rebooting the Installer Project
[4] Bug #482702 – Provide alternative stage3 tarballs using sys-apps/systemd

Plasma 5 and kdbus testing

Thanks to Mike Pagano who enabled kdbus support in Gentoo kernel sources almost 2 weeks ago. Which gives us the choice to test it. As described in Mikes blog post you will need to enable the use flags kdbus and experimental on sys-kernel/gentoo-sources and kdbus on sys-apps/systemd.

root # echo "sys-kernel/gentoo-sources kdbus experimental" >> /etc/portage/package.use/kdbus

If you are running >=sys-apps/systemd-221 kdbus is already enabled by default otherwise you have to enable it.

root # echo "sys-apps/systemd kdbus" >> /etc/portage/package.use/kdbus

Any packages affected by the change need to be rebuilt.

root # emerge -avuND @world

Enable kdbus option in kernel.

General setup --->
<*> kdbus interprocess communication

Build the kernel, install it and reboot. Now we can check if kdbus is enabled properly. systemd should automatically mask dbus.service and start systemd-bus-proxyd.service instead (Thanks to eliasp for the info).

root # systemctl status dbus
● dbus.service
Loaded: masked (/dev/null)
Active: inactive (dead)



root # systemctl status systemd-bus-proxyd
● systemd-bus-proxyd.service - Legacy D-Bus Protocol Compatibility Daemon
Loaded: loaded (/usr/lib64/systemd/system/systemd-bus-proxyd.service; static; vendor preset: enabled)
Active: active (running) since Fr 2015-07-10 22:42:16 CEST; 16min ago
Main PID: 317 (systemd-bus-pro)
CGroup: /system.slice/systemd-bus-proxyd.service
└─317 /usr/lib/systemd/systemd-bus-proxyd --address=kernel:path=/sys/fs/kdbus/0-system/bus

Plasma 5 starts fine here using sddm as login manager. On Plasma 4 you may be interested in Bug #553460.

Looking forward when Plasma 5 will get user session support.

Have fun!

KDE Plasma 5.3.1 testing

After several month of packaging in kde overlay and almost a month in tree, we have lifted the mask for KDE Plasma 5.3.1 today. If you want to test it out, now some infos how to get it.

For easy transition we provide two new profiles, one for OpenRC and the other for systemd.

root # eselect profile list
...
[8] default/linux/amd64/13.0/desktop/plasma
[9] default/linux/amd64/13.0/desktop/plasma/systemd
...

Following example activates the Plasma systemd profile:

root # eselect profile set 9

On stable systems you need to unmask the qt5 use flag:

root # echo "-qt5" >> /etc/portage/profile/use.stable.mask

Any packages affected by the profile change need to be rebuilt:

root # emerge -avuND @world

For stable users, you also need to keyword the required packages. You can let portage handle it with autokeyword feature or just grep the keyword files for KDE Frameworks 5.11 and KDE Plasma 5.3.1 from kde overlay.

Now just install it (this is full Plasma 5, the basic desktop would be kde-plasma/plasma-desktop):

root # emerge -av kde-plasma/plasma-meta

KDM is not supported for Plasma 5 anymore, so if you have installed it kill it with fire. Possible and tested login managers are SDDM and LightDM.

For detailed instructions read the full upgrade guide. Package bugs can be filed to bugs.gentoo.org and about the software to bugs.kde.org.

Have fun,
the Gentoo KDE Team

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.

 

Gentoo Qt Team March 2012 meeting

Date: 25 March 2012
Time: 1300 UTC
Place: #gentoo-meetings @freenode

The full meeting log can be found here. Meeting summary is written by kensington.

1) Roll call
hwoarang, johu, pesa, tampakrap, wired, yngwin

2) Qt 5
* pesa is working on it locally, and started a new eclass from scratch. He’ll
push to the overlay once upstream settles down, probably after a packaged alpha
is released (note that binary compatibility is not guaranteed with the final
release).

* Upstream is planning split tarballs for later releases, and we’re going to
follow that except for qtbase, which will probably be split the same as in Qt 4
– qt-{core,gui,sql,dbus}.

* Need to handle slotting of qmake. Any ebuild calling qmake directly should be
fixed to use eqmake{4,5}. Autotools etc. is sometimes used to detect qmake which
shouldn’t be broken. qmake{4,5} will probably suffice, but we should watch
upstreams / other distros to see what they do, and revisit the issue later.

3) qt4.eclass deprecation
* wired maintains a list of ebuilds still using the class:
http://dev.gentoo.org/~wired/checks/qt4.eclass.html and there are about 60 left
in the tree

* We should try to clear out the ebuilds in testing first. Since there is a
repoman warning, we can start filing bugs / stable requests to get them fixed.

4) Unmaintained/obsolete packages
* qgtkstyle – this is duplicated in qt-gui[gtkstyle]. hwoarang will lastrite it
so it can be treecleaned.

* qvfb – it is stuck at 4.6.3 and nothing in the tree uses it, so we don’t care
about it. Since is has no bugs there’s no need to remove it, so hwoarang will
set it to maintainer-needed.

5) Get eclass translation handling into official tree
* The code in the overlay covers enough cases to make it worth merging it to the
tree. pesa will submit the code to the dev mailing list for review before it it
is merged into qt4-r2.

* With regards to eclass development in the future, we want to change the
workflow to match how the KDE herd does it. That is, replace qt4-edge with
qt4-r2 and use the overlay as a staging area.

6) Open bugs
* Bug #398885 – x11-libs/qt-assistant-4.7.4 qdoc3 loops forever on arm & ppc
This is blocking 4.7.4 stabilising on arm and is therefore a high priority. ppc
already stabilised, so the bug might only affect certain machines. We should
retry the out-of-portage build (see comment #1) and investigate further.

* Bug #367583 – x11-libs/qt-dbus-4.7.2 –
../../include/QtCore/../../src/corelib/arch/qatomic_generic.h:197: error:
invalid conversion from ‘const void*’ to ‘void*’
We have two candidate patches to choose from – one eclass, one code. pesa will
try to get an opinion from upstream about the code patch.

* Bug #401557 – x11-libs/qt-core-4.8 –
hint: qt-4.8 : add a ewarn to recompile cairo *after* qt-4.8
wired will add a warning to either qt-core or qt-gui.

* Bug #398497 – /usr/include/qt4/Gentoo/gentoo-qconfig.h should be under package
manager control
This bug is probably the result of an oversight by the original eclass authors,
and we agree that the file should indeed be under package manager control.

* Bug #372721 – [qt overlay] x11-libs/libmeegotouch-9999 doesn’t compile
Nobody cares about this package, so pesa will remove it from the overlay and
mark it WONTFIX.

* Bug #388551 – x11-libs/qt-gui should depend on gnome-base/libgnomeui-2 when
USE=”gtkstyle” is enabled
During the last meeting we decided to add an elog, but nobody actually did it.

* Bug #285743 – “webkit” USE flag standardization
We decided to do this 2 years ago, but never got around to it. The flag mostly
has two meanings: (1) add support for HTML rendering and (2) build bindings for
WebKit. wired will propose (1) to the dev mailing list: “Enable support for the
WebKit html rendering engine”, and (2) can be a local flag description.

* Bug #404283 – media-gfx/imagemagick – convert: unable to close module `SVG’:
/usr/lib64/qt4/libQtGui.so.4: undefined symbol:
_ZN11QMetaObject11removeGuardEPP7QObject @
warning/module.c/UnregisterModule/1605.
wired will request more information from the reporter.

Gentoo KDE Team March 2012 meeting

Date: 22 March 2012
Time: 2000 UTC
Place: #gentoo-meetings @freenode

The full meeting log can be found here. Meeting summary is written by dastergon.

1) Roll call

alexxy, dilfridge, johu, mschiff, scarabeus, tampakrap

2) Electing a new team leader

nominees:

Accepted: dilfridge, johu
Refused: tampakrap, scarabeus

results:
johu -> dilfridge
dilfridge -> johu
tampakrap -> dilfridge
alexxy -> dilfridge
mschiff -> dilfridge
scarabeus -> dilfridge
———————-
dilfridge:5 – johu:1
———————-
dilfridge is the new KDE team leader with the majority of votes.
Congratulations!!!

3) Dropping RPATH from installed binaries

Add a RPATH entry for every library dir that is not in the system library
directories in ld.conf are not automatically considered as system library
dirs, but only some static list of dirs.
Everyone agreed on RPATH removal. We will introduce a patch with KDE SC 4.8.2
to remove the RPATH and move it to the main tree.

4) Bugs

* Remove hard dep on media-libs/phonon from kde-base/kdelibs
https://bugs.gentoo.org/show_bug.cgi?id=356681
https://bugs.gentoo.org/show_bug.cgi?id=388041
Upstream says “technically you can replace phonon with qt-phonon, but that’s
just stupid because you lose functionality”. Another argument against it, is
that qt-phonon will be removed with qt5. We wont fix the bug and keep phonon as
hard dep. johu will take care of the bug after meeting summary is available.

* Eclass problem with handbook without LINGUAS.
https://bugs.gentoo.org/show_bug.cgi?id=372457
The handbook eclass code is pretty confusing for all in meeting present
members. It was written by reavertm. We decided that we will mail reveartm to
fix handbook eclass code, because he has the most knowledge in it. dilfridge
will take care of contacting him, it’s his first lead task.

* Revise the change “semantic-desktop? -> semantic-desktop=”.
https://bugs.gentoo.org/show_bug.cgi?id=396491
Some packages rely on semantic-desktop capabilities in other ones. tampakrap
is volunteers to take care of the bug.

5) Open floor

* KDE 4.8 stabilization
KWin does not build anymore without opengl support. kde-base/kmail-4.8.1
crashes, but upstream patch can be backported. KDE SC 4.8.1 has tons of
bugfixes, compared to to 4.8.0. The majority votes for KDE 4.8.1 as stable
candidate. johu will prepare stabilization.

* Test failures
creffett brought up dbus-related test failures. johu recommended to get
virtual-dbus eclass running. dilfridge suggested if one or two test fails
or restrict. The problems with virtual-dbus is that you can’t run bash
commands in it’s environment. creffett will be responsible for this.

* New members
Welcome to three new members of the project: creffett, kensington and
dastergon. They are in the process to become gentoo developer and mentored by
tampakrap. creffett and kensington have already open ‘new developer’ bug.
dastergon doesn’t have an open bug yet.

* Comeback
scarabeus re-joined KDE herd. Welcome back!!!

* Reduced work time
mschiff mentioned that he will not have much time for the KDE herd due to
real life priorities, he will be back in may. tampakrap will spent most of his
time for gentoo infra team.

Meeting bits

Yesterday (2012/01/16 20:00 UTC) we had the first Gentoo KDE team meeting this year. The meeting happened in #gentoo-meetings on freenode.

  • Participants: alexxy, dilfridge, jmbsvicetto, johu, mschiff, tampakrap, Thev00d00
  • Agenda
  • Log
  • Lead election is delayed, because 12 months not over
  • We keep kdepim-4.4 in tree as long as it works and provide kdepim-l10n package
  • Kdeenablefinal build feature will be removed today
  • Phonon xine backend will be removed in 15 days
  • We expect no big issues with Qt 4.8,  only kdenlive is not building at the moment
  • eselect boost vs. latest boost is not a Gentoo KDE scope only issue, we will move the discussion to the gentoo-dev mailing list
  • … read log 😛 or wait for the full summary by tampakrap
  • My netbook had a kernel panic while the meeting  :-/
After the meeting i joined the Gentoo Qt team.

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…