notes on gbp package building
The goal is to bring upstream release 1.8.0v to Debian.
Initially I pulled directly from the source, GitHub, and then placing the contents into a private Git repository that I have locally on a Gitea server. I was able to build the patches for opensnitch using this repository and build the package using dpkg-buildpackage -us -uc -b from nodes on my LAN.
Problem: gbp Won't Build for Team Members
The problem with porting the build is that upstream/1.8.0 doesn't exist on the Debian Salsa Gitlab repository. It's unclear to me what was wrong, but when the team using gbp would run gbp commands against my fork, they could not build the packages.
Therefore, gbp will need to know that upstream/1.8.0 exists. Also existing ../opensnitch_*.orig.tar.gz files left in build directory may impact patch application. gbp buildpackage may use existing files matching and reuse it without verifying current upstream/1.8.0 branch. The flag --git-force-create may be applied to override default behavior. Suggested local gbp.conf may be as follows:
[buildpackage]
export-dir = /tmp/osnitch-out
purge = False
builder = dpkg-buildpackage -us -uc -b
Additional issues in current build:
- debian/rules not executable (644, not 755)
- eBPF/clang warnings (nocf_check ignored, anonymous structs are a Microsoft extension, etc.)
- ~40 setuptools _Warning: Package 'opensnitch.i18n.
' is absent from packages configuration + setup.py install is deprecated - dpkg-gencontrol warnings about unused/undefined substvars
All are harmless noise. The minor debian/rules issue can be solved with permissions, but dpkg-buildpackage auto-fixes it.
Current Situation: Apparent Failed Tests in Build for Unprivileged User
As of now, the current failure is that that without privileged root access, CAP_NET_ADMIN cannot manipulate nftables and is expected to fail, which I will address in a specific section titled CAP_NET_ADMIN Analysis.
CAP_NET_ADMIN Analysis
CI log showing ERR/WAR lines (nftables: error applying changes: netlink receive: operation not permitted, Error reading firewall configuration from disk, etc.) alongside --- PASS results caused confusion. Traced this down to source:
The tests only check config-struct fields, never subsystem success:
| Line | Description |
|---|---|
| daemon/ui/client_test.go:62-81 - validateConfig | The only assertion function called by TestClientDefaultConfig (line 120) and TestClientReloadingConfig (lines 139, 161) — checks exactly: ProcMonitorMethod(), GetFirewallType(), InterceptUnknown(), DefaultAction(), DefaultDuration(), config.Server.Address. Nothing about whether nftables/conntrack/tasks actually succeeded. |
| daemon/ui/client.go:121-144 - ProcMonitorMethod(), InterceptUnknown(), GetFirewallType() | Just return c.config. |
| daemon/ui/config_utils.go:92-107 | The config gets applied regardless of whether the reload succeeded — by explicit design. |