KDE on FreeBSD
We take care of Qt, CMake and KDE-related ports on FreeBSD, making sure they run well and working directly with upstream as much as we can.
KDE on FreeBSD website: http://FreeBSD.kde.org.
Mailing list: https://mail.kde.org/mailman/listinfo/kde-freebsd.
- IRC: #kde-freebsd on irc.freenode.net.
Current kde@ team
Adriaan de Groot (firstname.lastname@example.org)
- Alonso Schaich (alonso@)
- Max Brazhnikov (makc@)
- Raphael Kubo da Costa (rakuco@)
- Tobias Berner (tcberner@)
Team best practices
Release preparation: steps to follow when a new KDE release is out.
Quarterly report summaries: summary of kde@'s activities by quarter, for FreeBSD's quarterly status report.
Someone should take a look in SBIG Universal Driver: http://indi.sourceforge.net.
Get rid of the changes to QT_IMPORTs_DIR and QT_PLUGINS_DIR in files/patch-Modules_FindQt4.cmake. Right now, each Qt port such as graphics/qt4-imageformats or databases/qt4-sqlite-plugin install part of the Qt hierarchy that FindQt4.cmake expects to fully exist. If a port only depends on certain Qt ports, the full directory structure may not exist when CMake is called. One way to fix it would be to make a port such as devel/qmake4 create the whole directory hierarchy, but such kind of change should be done when a new Qt release comes out.
We need network support in Solid. Instead of porting NetworkManager, we might write our own backend. As of May 31st, 2012, it seems that olivierd@ is porting Wicd to FreeBSD.
- KInfoCenter needs to learn about the new USB stack available since FreeBSD 8.
- We'll need to replace Solid HAL backend with a devd(8) one sooner or later.
KDE Frameworks5, Plasma5, Applications16 Todo
The following needs to be done or decided to get an up to date KDE Desktop into ports (KDE Frameworks itself is not really affected by this, it mostly concerns Plasma5 and up to date Applications16).
First of all, note, that KDE Frameworks5 based applications will run just fine inside a KDE4 desktop [There might be some issues with kwallet].
We need to decide what we want to do with KDE Applications:
Solution 1: Allow for a complete KDE4 based desktop, with all (outdated) applications present as well as the new ones from Applications16
-> move all non-suffixed kde4 applications from foo to foo-kde4. Add upgraded versions as new ports.
Solution 2: Keep some KDE4 based applications around:
-> move said non-suffixed kde4 applications from foo to foo-kde4, and the other suffixed ones from bar-kde4 to bar, and upgrade them.
Solution 3: Only track up to date KDE Applications:
-> move all suffixed applications from bar-kde4 to bar, and upgrade them.
Each of the above solutions has its own issues. Personally I (tcberner) prefer Solution 3, as for example Solution 1 doubles the number of application ports, and Solution 2 leads to the question which do we keep as KDE4 version, and why? (also dependency and conflicts hell).
- Do we need to keep KDE4 at all. It is EOL, Qt4 is also EOL.
The look and feel of Plasma5 is no[t that much] different from that of KDE4.
We have the following issue with KDEPim:
KDEPim 16.* requires Qt5WebEngine, which we do not have (see Qt Todo).
- KDEPim 4.* install conflicts with Plasma5 components
So in short, at the moment we do not have the ability to provide KDEPim on a plasma5 based desktop. There are multiple possible solutions:
- Buy drugs/chocolates, port www/qt5-webengine
Needed for Solution 3.
Patch KDEPim4s akonadi, baloo, <maybe others> to install their libs/dbus-services/... with a suffix -kde4.
This would also imply Solution 1 or Solution 2 above.
- Patch KDEPim 16 to use www/webkit-qt5.
This is possible, but requires a lot of patches, as WebEngine is used everywhere (at the moment, with some components disabled, it is ~100 patches). Note, that this approach carries some security issues, as webkit-qt5 is (thought to be) way less secure as qt5-webengine (as it doesn't receive [m]any security fixes). This could maybe be adressed by replacing www/webkit-qt5 with a fork. See below.
Alternatively needed for Solution 3.
- Don't ship KDEPim anymore -- not really an option.
- We need to finished the port of www/qt5-webengine
- More and more applications will require it in the future, also applications that are not part of KDE.
- We should look into replacing www/webkit-qt5 by a fork that is actively maintained, and receives patches, like for example:
Cleanup of the kf5-* and plasma5-* ports
We should double-check that all the primary CATEGORIES are sensible
COMMENT need to be looked at
pkg-descr files and their WWW: entry should be checked, maybe WWW should just be kde.org in general. At the moment the frameworks mostly point to their api-documentation or their project page.