Context
#508 adds an EGL-based DRM modifier enumeration whose libEGL.so.1 is dlopen'd at runtime (electron/native/pipewire-capture/csrc/dmabuf_modifiers.c:44). Nothing links libEGL, so nothing puts it on the binary's RPATH, and the dlopen fails on any host without an ld.so.cache entry for it — NixOS being the case we package for.
The PR handles this: nix/pipewire-helper.nix adds libglvnd to the patchelf'd rpath alongside the libpipewire entry that already existed for the same reason. The fix is present. It has never been built.
Why it can't be verified in CI today
nix-build.yml runs on workflow_dispatch, push to main, and a Monday 06:00 UTC cron — not on pull_request. So a packaging change merges unverified and is first exercised either by the weekly cron or by a NixOS user.
The failure mode is quiet, which is what makes it worth tracking rather than assuming:
So the symptom on NixOS is "the fix didn't work", with the diagnostics actively pointing the other way.
What would close this
- Build
nix/pipewire-helper.nix on a NixOS host (or in a Nix container) and confirm the helper's RPATH resolves libEGL.so.1 — patchelf --print-rpath on the output binary, then an actual recording.
- Confirm the enumeration returns more than
LINEAR/INVALID there, i.e. that the dmabuf path actually engages.
Note that fixupPhase runs patchelf --shrink-rpath, and build.rs passes -Wl,--disable-new-dtags on purpose — the existing comments in pipewire-helper.nix explain the interaction. A change here that looks correct can still be shrunk away, which is precisely why reading the expression is not a substitute for building it.
Related
Context
#508 adds an EGL-based DRM modifier enumeration whose
libEGL.so.1isdlopen'd at runtime (electron/native/pipewire-capture/csrc/dmabuf_modifiers.c:44). Nothing links libEGL, so nothing puts it on the binary's RPATH, and the dlopen fails on any host without anld.so.cacheentry for it — NixOS being the case we package for.The PR handles this:
nix/pipewire-helper.nixaddslibglvndto the patchelf'd rpath alongside the libpipewire entry that already existed for the same reason. The fix is present. It has never been built.Why it can't be verified in CI today
nix-build.ymlruns onworkflow_dispatch,pushtomain, and a Monday 06:00 UTC cron — not onpull_request. So a packaging change merges unverified and is first exercised either by the weekly cron or by a NixOS user.The failure mode is quiet, which is what makes it worth tracking rather than assuming:
LINEAR/INVALIDmodifiers get advertiseddmabuf-import available: true, and nothing appears in the log unlessOPENSCREEN_PIPEWIRE_DEBUGis setSo the symptom on NixOS is "the fix didn't work", with the diagnostics actively pointing the other way.
What would close this
nix/pipewire-helper.nixon a NixOS host (or in a Nix container) and confirm the helper's RPATH resolveslibEGL.so.1—patchelf --print-rpathon the output binary, then an actual recording.LINEAR/INVALIDthere, i.e. that the dmabuf path actually engages.Note that
fixupPhaserunspatchelf --shrink-rpath, andbuild.rspasses-Wl,--disable-new-dtagson purpose — the existing comments inpipewire-helper.nixexplain the interaction. A change here that looks correct can still be shrunk away, which is precisely why reading the expression is not a substitute for building it.Related
pull_requesttonix-build.ymlwould close the general gap, not just this instance. Worth considering separately — it is the reason this issue has to exist at all.dmabuf_modifiers.c:44).