Skip to content

packaging: build the Debian/OBS packages with multiprocess enabled - #3265

Merged
jamescowens merged 1 commit into
gridcoin-community:developmentfrom
jamescowens:packaging/obs-multiprocess
Aug 20, 2026
Merged

packaging: build the Debian/OBS packages with multiprocess enabled#3265
jamescowens merged 1 commit into
gridcoin-community:developmentfrom
jamescowens:packaging/obs-multiprocess

Conversation

@jamescowens

@jamescowens jamescowens commented Aug 14, 2026

Copy link
Copy Markdown
Member

ENABLE_MULTIPROCESS defaults OFF and neither debian/rules nor debian-testnet/rules sets it, so every package built through OBS is monolithic.

With production CI now enabling multiprocess on all seven artifact jobs, the distribution packages are the only shipped Gridcoin binaries without the GUI/node split. A user installing from a distro repository gets a build whose --help advertises -multiprocess and which cannot do it.

What changed

Both recipes pass -DENABLE_MULTIPROCESS=ON, and both control files gain the Cap'n Proto build dependencies:

 capnproto,
 libcapnp-dev (>= 0.9),

capnproto supplies the code generator, libcapnp-dev the runtime. The >= 0.9 floor is not arbitrarysrc/ipc/libmultiprocess/CMakeLists.txt calls find_package(CapnProto 0.9) and hard-fails below it:

message(FATAL_ERROR "Cap'n Proto 0.9 or newer is required, but version ${CapnProto_VERSION} was found.")

Expressing the floor in Build-Depends means a distribution that cannot satisfy it reports the package unresolvable, rather than starting a build that dies part way through with a version-mismatch error.

libmultiprocess is a vendored subtree and needs no packaging. ${shlibs:Depends} already covers the libcapnp runtime dependency for both binary packages, so no manual Depends entry is needed.

The split packaging

The daemon and GUI are separate binary packages, so multiprocess needs both installed. That is now stated rather than left to be discovered — the GUI package Suggests the daemon, and its description explains that -multiprocess attaches over IPC to a daemon that is already running and does not start one itself.

The testnet recipe uses its own package names (gridcointestnetd, gridcointestnet-qt) and refers to those, not the mainnet ones.

What is NOT verified — please check before merging

No OBS build was run. More importantly, the distributions the OBS project targets are configured in OBS, not in this repository, so I cannot determine from here what the >= 0.9 floor does to the target list. A target shipping an older Cap'n Proto will go unresolvable rather than quietly producing a monolithic package — which is the right failure mode, but it means that distribution stops receiving packages until it is dropped or the floor is handled differently.

If any current target predates Cap'n Proto 0.9, that decision needs making before this lands. The alternative shape — probing pkg-config --atleast-version=0.9 capnp in debian/rules and degrading to a monolithic build — was deliberately not taken, because it makes package contents vary silently by distribution.

Related

Rebased onto development after #3264 merged. The two did conflict as predicted — both debian/rules and debian-testnet/rules, since this PR inserted -DENABLE_MULTIPROCESS=ON directly above the -DDEFAULT_UPNP=ON line #3264 deletes.

Resolved the way both PR bodies said it should be: keep -DENABLE_MULTIPROCESS=ON, drop -DDEFAULT_UPNP=ON. -DENABLE_UPNP=ON is retained in both files, so UPnP support stays compiled in and only the start-enabled default is gone — #3264's intent preserved.

The diff is now purely additive (26 insertions, 0 deletions): one -DENABLE_MULTIPROCESS=ON line per rules file plus the Cap'n Proto build-deps and Suggests: in each control file.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Enable multiprocess (GUI/node split) in Debian/OBS packaging so distributed binaries match CI artifacts and support -multiprocess, while documenting the daemon dependency for multiprocess mode.

Changes:

  • Enable -DENABLE_MULTIPROCESS=ON in both debian/rules and debian-testnet/rules.
  • Add Cap’n Proto build dependencies (capnproto, libcapnp-dev (>= 0.9)) for multiprocess IPC support.
  • Document the GUI ↔ daemon relationship for multiprocess mode via Suggests: and extended package descriptions.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File Description
debian/rules Enables multiprocess at CMake configure time for mainnet builds.
debian/control Adds Cap’n Proto build-deps and clarifies GUI multiprocess requirements via Suggests/description.
debian-testnet/rules Enables multiprocess at CMake configure time for testnet builds.
debian-testnet/control Mirrors mainnet packaging updates for testnet dependencies and documentation.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread debian/control Outdated
Comment thread debian-testnet/control Outdated
Comment thread debian/control
Comment thread debian/control
Comment thread debian-testnet/control
Comment thread debian-testnet/control
ENABLE_MULTIPROCESS defaults OFF and neither debian/rules nor
debian-testnet/rules set it, so every package built through OBS is monolithic.
Now that the production CI enables it on all seven artifact jobs, the distribution
packages are the only shipped Gridcoin binaries without the GUI/node split: a user
installing from a distro repository gets a build whose --help advertises
-multiprocess and which cannot do it.

Both recipes now pass -DENABLE_MULTIPROCESS=ON, and both control files gain the
Cap'n Proto build dependencies: capnproto for the code generator and libcapnp-dev
for the runtime. The version floor is expressed as (>= 0.9) because that is what
the vendored libmultiprocess subtree requires -- src/ipc/libmultiprocess
/CMakeLists.txt calls find_package(CapnProto 0.9) and fails configure below it.
Stating the floor in Build-Depends means a distribution that cannot satisfy it
reports the package as unresolvable, rather than starting a build that dies part
way through with a version-mismatch error.

libmultiprocess itself is a vendored subtree and needs no packaging.
${shlibs:Depends} already covers the libcapnp runtime dependency for both binary
packages, so no manual Depends entry is required.

The Debian packaging splits the daemon and the GUI into separate binary packages,
so multiprocess needs both installed. That is now stated rather than left to be
discovered: the GUI package Suggests the daemon package, and its description says
that -multiprocess attaches over IPC to a daemon that is already running and does
not start one itself. The testnet recipe uses its own package names
(gridcointestnetd, gridcointestnet-qt) and refers to those.

NOT verified through an OBS build. The distributions the OBS project targets are
configured in OBS rather than in this repository, so the effect of the (>= 0.9)
floor on the target list cannot be determined from here -- a target shipping an
older Cap'n Proto will become unresolvable instead of producing a monolithic
package. That list is worth checking before this merges.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@jamescowens
jamescowens force-pushed the packaging/obs-multiprocess branch from 744dc7c to 5b92bd0 Compare August 19, 2026 14:51
@jamescowens
jamescowens merged commit dd1dec1 into gridcoin-community:development Aug 20, 2026
27 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants