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

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

* 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 @
wired will request more information from the reporter.

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.