Skip to content

Building and installing

Jump to bottom Edit New page
Ivailo Monev edited this page Sep 25, 2023 · 235 revisions

Warning

Katana and KDE are not 100% compatible and installing Katana on system with KDE installed will most likely wreck havoc!

In case you face a build failure, please be patient. From time to time changes (not only to this project) introduce regressions which we may take care of in a few days as this is not a small project and it takes a good amount of time and effort to maintain it. Feel free to open an issue but mind that sometimes it lies elsewhere, more often than you think and root deep.

Mirrors

The project is currently hosted on multiple sites, when online services fail to deliver check the mirrors:

Pre-build packages

Packages for Debian 12 provided here, packages for FreeBSD 13.2 provided here. Contributions welcome.

Package files

In the main repo you can find packaging directory which holds files that can be used to create binary packages for some distributions. Feel free to make pull requests with packages files for your favourite distro.

Note that Katana is packaged in such a way that all optional and recommended dependencies will be installed, if possible. If, for example, a dependency is not installable from the official repositories of some distribution than it may not be installed.

Requirements

This list is incomplete and contains mostly runtime dependencies which may not be obvious, CMake will let you know about found and otherwise dependencies so make sure to review the output when building. If desired install them and retry the build process.

CMake modules shipped with kdelibs can give you a hint about what the project requires.

Build-time

CMake >= 3.0.2

Katie >= 4.14.0

Runtime

X.Org

  • xmessage >= ???
  • xprop >= ???
  • xrandr >= ???
  • xrdb >= ???
  • xsetroot >= ???
  • xauth >= ???
  • setxkbmap >= ???
  • iceauth >= ???
  • xkill >= ???

shared-mime-info >= 0.91

media-player-info >= ???

tzdata >= ???

Lm_sensors >= ???

PCI Utilities >= ??? (alternatively Busybox build with CONFIG_LSPCI and CONFIG_LSUSB)

icoutils >= ???

ctags >= ???

cppcheck >= ???

xdg-utils >= ???

DejaVu Fonts >= ???

DjVuLibre >= ???

FreeRDP >= ???

lrzsz >= ???

cryptsetup >= ???

QEMU >= ???

TeX Live >= ???

libqrencode >= ???

systemd >= ??? (alternatively ConsoleKit2)

NetworkManager >= ??? (alternatively connman or systemd)

ntp >= ??? (alternatively ntpsec)

util-linux >= ???

Optional

MPV >= 0.23.0

Building without MPV can significantly decrease the memory requirements but you will not get sound notifications, media files previous, etc.

A word of advise

When building with non-standard prefix (e.g. /opt/kde4) you must have the following things in mind:

  • Everything that will look for kdelibs (e.g. kde-workspace, kde-extraapps, etc.) must be aware of the prefix. For CMake to be able to find the KDELibs4 config KDELibs4_DIR must be exported. For example, if kdelibs is installed with /opt/kde4 as prefix KDELibs4_Dir has to point to /opt/kde4/share/cmake.

  • Post installation you will have to ensure that the libraries installed can be found during runtime. This can be done via custom config in /etc/ld.so.conf.d/ or via LD_LIBRARY_PATH (if supported, musl and uClibc may not).

  • Ensure that binaries can be found either via PATH override or symlinks (not recommended). While internally installed programs, such as kde4-config, will be found other programs, such as xdg-open, will be unaware of them if they are not in PATH.

Some Operating Systems, such as the hardened Gentoo musl flavour, are a bit restrictive and all of the notes are very host dependent. You can read and get an idea how this can be achieved from Beyond Linux From Scratch. While such installation is supported you really should consider normal installation when you know that it will not conflict with KDE4 or KDE5.

If you want to build things fast at the cost of slight runtime performance hit then you can set CMAKE_BUILD_TYPE to MinSizeRel. This will tell the compiler not to optimize for performance and reduce the build time a lot. Use of Ninja is likely to help in this matter too.

Building and installing sub-projects

git clone --depth=1 https://github.com/fluxer/katana
cd katana
./build.sh

If you decide to build from a stable release not via the script make sure you check (on regular basis, or just watch the repository) for changes. Also the latest source code is not hosted here. Repositories are synced once a few days usually, sometimes more often (e.g. during early development of new features).

Host setup

The open files limit on FreeBSD, NetBSD, OpenBSD and DragonFly BSD is known to be low thus you may have to increase it to a more reasonable value such as 4096. To increase it temporary use the following command:

ulimit -n 4096

Note that you have to do that prior to starting Katana Desktop Environment, i.e. in the parent Shell process. To increase it permanently or for specific applications look into the documentation of the distribution you are using it on.

Some services, such as ConsoleKit2 which is used for power management, require the system D-Bus daemon to be running. The daemon is usually started by init system service. Again, refer to your distribution documentation for that.

Add a custom footer
Add a custom sidebar

Clone this wiki locally