Add Nix build system for development

[fnune]

Refreshed against current master. Most of the original PR is already upstream, thanks for picking that up. What's left is the Nix-specific stuff plus the small extras needed to make a build from build/ work end to end (including install / upgrade / remove). Distro installs are untouched.

This PR adds Nix flake support to enable clean, isolated development without installing dependencies system-wide.

Screencast_20251116_134654.webm

Motivation

Building Octopi currently requires manually cloning and installing alpm_octopi_utils, qt-sudo, Qt6 libraries, vala, and other tools system-wide. This makes it difficult to test changes without replacing your system installation of Octopi, pollutes the system with development dependencies, etc. The flake provides isolated, reproducible builds with all dependencies managed automatically in a dev shell with Qt6, CMake, vala, and friends. It builds alpm_octopi_utils and qt-sudo from source and sets up the env so you can build with CMake or qmake just like the existing instructions.

Quick start

# Install Nix if needed
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

git clone https://github.com/aarnt/octopi
cd octopi
nix develop
mkdir -p build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
./octopi

Optional: echo 'use flake' > .envrc for direnv.

Code changes

These are the minimum needed to let an Octopi running from build/ work end to end without changing anything for /usr/bin/octopi.

1. src/unixcommand.cpp::isOctoToolRunning(): accept allowed paths from an OCTOPI_ALLOWED_PATHS env var. The dev shell sets it to /usr/bin:<repo>/build. If unset, the original /usr/bin/<tool> check is used unchanged.

2. src/unixcommand.{cpp,h}::getOctopiHelperPath(): prefer a sibling octphelper next to the running binary, fall back to ctn_OCTOPI_HELPER_PATH. For a distro install the fallback wins bit for bit (no /usr/bin/octphelper exists). For a dev build the sibling exists. Updates the helper-existence checks in main.cpp, notifier/main.cpp, cachecleaner/main.cpp, the qt-sudo invocations in src/unixcommand.cpp, the in-terminal helper command in src/terminal.cpp, and the TCP handshake recognition in isOctopiHelperRunning().

3. helper/octopihelper.cpp::isProcessRunningFromPath(): widen the trusted path set from "starts with /usr/bin" to also accept callers co-located with the helper itself, provided the helper's directory is not group- or world-writable. Same path-based trust the existing check already uses (integrity from filesystem permissions on the trusted dir). Distro install trusted dir is /usr/lib/octopi/, owned by root, no change. Dev build trusted dir is the build dir, owned by the user who is already typing their qt-sudo password to invoke the helper, so no new escalation primitive.

No env vars are passed to the helper, no sudoers tweaks required.

All existing build methods (qmake, CMake, PKGBUILD) continue to work unchanged.

What I tested

On Arch (CachyOS, pacman 7.1.0 / libalpm 16.0.1), with the system octopi 0.19.0-1 package installed in parallel.

Inside nix develop from build/:

• cmake .. -DCMAKE_BUILD_TYPE=Release && make -j$(nproc) produces octopi, octopi-notifier, octopi-cachecleaner, octopi-repoeditor, octphelper.
• ./build/octopi launches.
• "Check updates" (Ctrl+K) prompts via qt-sudo and reports outdated packages correctly.
• Installing htop from the UI succeeds. /usr/lib/octopi/octphelper.log shows Path of PID ... is <repo>/build/octopi and Exec as root: /usr/bin/pacman -S --noconfirm ... htop.
• Removing htop from the UI succeeds (same log pattern, pacman -R).
• System upgrade from the UI runs to completion.

Negative case:

• env -u OCTOPI_ALLOWED_PATHS ./build/octopi shows the existing You must use "/usr/bin/octopi" to run Octopi popup and exits 251. Gate unchanged when the env var is not set.

Distro install path:

• /usr/bin/octopi (system package) still launches and performs transactions normally, without reading OCTOPI_ALLOWED_PATHS and with getOctopiHelperPath() falling through to /usr/lib/octopi/octphelper.

git status after nix build is clean (result/ is gitignored).

[aarnt]

Hi Fausto, thanks for this nice contrib!

I've never used Nix before, but people use to say very good things about this project (both distro and pkg manager).

I see you did not change "helper/octopihelper.cpp" in your PR.
Did you try upgrading, installing or removing a package with the executables installed in "/path/to/your/build" ? I think helper will veto the transaction. Take a look at "bool OctopiHelper::isProcessRunningFromPath(pid_t pid)" method from "octopihelper.cpp".

By the way, I was curious to know which feature you were trying to implement :-)

[fnune]

By the way, I was curious to know which feature you were trying to implement :-)

This was my feature idea: showing a highlight if something within "news" is related to a package you have installed.

However, I realized that the data for news is not structured enough to be able to get a package name reliably. E.g. sometimes the message just says "Plasma 6.5 desktop" :/

[fnune]

I see you did not change "helper/octopihelper.cpp" in your PR. Did you try upgrading, installing or removing a package with the executables installed in "/path/to/your/build" ? I think helper will veto the transaction. Take a look at "bool OctopiHelper::isProcessRunningFromPath(pid_t pid)" method from "octopihelper.cpp".

I saw other hard-coded paths. I think they may need to be updated for things to work with Nix. Maybe the full functionality (as you suggest) is not working properly when building with Nix.

I will try more things later today and report back! If there are incremental changes that can be upstreamed more slowly (e.g. using the standard paths helpers) maybe those are good contributions, too?

[aarnt]

Hi @fnune

I merged most of your updates to make qt-sudo path agnostic.
Did not merge *nix specific code. I'm waiting for your next tests.

Thanks!

[fnune]

@aarnt I rebuilt the PR and worked on it until I was able to run the important stuff from the Nix-built binary:

• System upgrade
• Installing a package (tried htop)
• Removing a package

One caveat: the Nix build builds against a Nix-bundled libalpm, but it may differ from the host's version. I would maybe recommend using this for development and not for production builds.

I'm not sure if that makes the whole concept less appealing to you. But anyway, here's the PR. Of course, take it or leave it! :)