{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibkj7die3spt3rijeaqae2ims4ohx75ol2l2gccxblyszks6jumwa",
    "uri": "at://did:plc:6dmfe46c76jjenq3kaxc5eds/app.bsky.feed.post/3mffxnfy2s4g2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifl4z2d7gocrn764fqiie6bfh2femyopynun6z365d6he4yziroyu"
    },
    "mimeType": "image/png",
    "size": 5624
  },
  "path": "/blog/distrobox-kde",
  "publishedAt": "2026-02-22T00:00:00.000Z",
  "site": "https://pavanportfolio.droptools.site",
  "textContent": "As part of my work on the Mancala for Season of KDE, I needed to compile the backend mankalaengine from source. Running Ubuntu 24.04 LTS on my host system, I wanted to keep it clean and avoid dependency conflicts while designing digital assets. I decided to build the C++ engine inside an isolated container using Distrobox.\n\nWhat seemed like a straightforward compilation turned into a great learning experience in container troubleshooting and build systems. Here is how I got it working.\n\n## The False Start: openSUSE Tumbleweed\n\nThe KDE documentation highly recommends using Distrobox with a rolling-release distribution to ensure access to the latest KDE Frameworks. Naturally, I started with openSUSE Tumbleweed:\n\n\n    distrobox create --image docker.io/opensuse/tumbleweed --name kde-dev\n    distrobox enter kde-dev\n\n\nHowever, the container instantly crashed on startup with this error:\n\n\n    sed: can't read /etc/zypp/zypp.conf: No such file or directory\n\n\n**The Fix** : It turns out the default opensuse/tumbleweed image on Docker Hub is a highly stripped-down \"micro\" image. It lacks core configuration files that Distrobox expects during its initialization script. Rather than fighting the micro-image, I pivoted to an image guaranteed to have the standard toolchains out of the box.\n\n## The Solution: Arch Linux\n\nArch Linux is heavily used in the KDE development community and plays perfectly with Distrobox. I cleaned up the broken container and spun up an Arch environment:\n\n\n    distrobox stop kde-dev\n    distrobox rm kde-dev\n    distrobox create --image docker.io/archlinux:latest --name kde-dev\n    distrobox enter kde-dev\n\n\nThis time, the initialization was flawless. Once inside the container, I pulled down the required KDE build dependencies using pacman:\n\n\n    sudo pacman -Syu base-devel cmake extra-cmake-modules ki18n\n\n\n## The Build System Hiccup\n\nWith the dependencies installed, I navigated to my mankalaengine directory (which Distrobox automatically mounts from the host) to configure the build:\n\n\n    mkdir build\n    cd build\n    cmake ..\n\n\nThis immediately threw a CMake error:\n\n\n    The C++ compiler \"/usr/bin/c++\" is not able to compile a simple test program.\n\n\nWhile the C++ compiler was installed, the underlying build automation tool was missing. In the KDE ecosystem, the standard is Ninja—a lightning-fast build system designed to replace traditional make.\n\nI installed Ninja, cleared the broken build cache, and reconfigured CMake to use it:\n\n\n    sudo pacman -S ninja make\n    rm -rf *\n    cmake -G Ninja ..\n\n\n## Compiling and Running\n\nWith CMake successfully generating the Ninja blueprints, compiling the engine was just a single command away:\n\n\n    ninja\n\n\nThe build finished in seconds. To verify everything worked, I wanted to test out the Text User Interface (TUI) examples included in the repository.\n\nIn KDE projects, CMake is usually configured to place all compiled binaries into a central directory. I navigated to the bin folder and launched the Kalah variant:\n\n\n    cd bin/\n    ./kalahtui\n\n\nThe terminal interface booted up perfectly, drawing the board and allowing me to play directly against the engine's AI.\n\n## Conclusion\n\nUsing Distrobox is a game-changer for KDE development. Even with a few initial hiccups regarding container images and build tools, having a disposable, bleeding-edge Arch Linux environment running seamlessly alongside my Ubuntu 24.04 LTS host makes compiling C++ projects incredibly efficient. I get the stability of an LTS release for my daily work while accessing the latest KDE Frameworks in an isolated container.",
  "title": "Containerized KDE Development: Building the Mankala Engine with Distrobox"
}