Change:
}; in lib.mapAttrsToList (script: source: '' rm -f ${script} <del> makeWrapper ${python3Packages.python.interpreter} ${script}  --set PYTHONPATH "$PYTHONPATH:${outRef}/share/cadence"  ''${qtWrapperArgs[@]}  --add-flags "-O ${source}" </del> <ins> makeQtWrapper ${source} ${script}  --prefix PATH : "${lib.makeBinPath [ jack_capture # cadence-render pulseaudioFull # cadence, cadence-session-start ]}" </ins> '') scriptAndSource; meta = {

Discussion:
cc maintainer: Some of the tools included with cadence need jack. For example catia. When I run it, I get a dialog saying: ` system: host os: multi-user?: sandbox: version: channels(bart): channels(root): nixpkgs:
A temporary workaround is to call cadence like the following, I don't remember what the correct way to deal with .so libraries and python is;
It still can't see jackdbus and I don't know how to get the dbus.mainloop.pyqt5 thing, see also The current tree seems to have a patch for it
Libraries are generally patched like this: The place to patch:
Is this held up because we don't know what to do or because we don't have time to do it? Also, is there known work-around?
See for how to fix it. I use neither JACK or cadence so I cannot test it but I would expect it to work. Workaround is described in the .
Thanks! I didn't get the impression that it worked for
I think we can close this after merging . The problem with cadence, author has not enough time and it's full of bug, you fix one you'll discover 2.
I can confirm that, having tested your change (thanks very much!), it gets past the error dialog, but still has issues communicating with jack. However, this is only one of several jack clients in nixpkgs that exhibit the same issue. IOW, I believe this is a larger problem that just this instance. In general, I'm finding that some jack client pkgs work with the jack service and many others do not. Stated another way, jack functionality in NixOS seem largely (though not totally) to be broken in general.
I'll add that, with this change, cadence is definitely able to communicate with the jack server. However, cadence is essentially a launcher. likely did fix cadence, but the individual apps that it launches within the pkg remain broken. In particular, catia still seems to be broken.

Yes, did you have some : Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started or Client name = xxxxx conflits with another running client Im not able to use jack anymore, but same with jack_control, i don't think it's cadence problem here.
I did indeed. And I've seen that kind of thing with several other jack apps. I think you did fix the cadence issue, but I believe it's more widespread. My own experience is with jack1 (vs jack2/jackdbus) and that in Debian. I'm not very knowledgeable about jack2 and I wonder if there's some subtle differences in the way the clients interact with the respective jack versions that accounts for some working and others not.
And it's works with pulseaudio bridge, renoise jack ... I think we have dirty bug in jack2/dbus yes, try to figure out what.
Off-hand, I can say that ardour, hydrogen, bristol, patchage all work for me. Ingen and ecasound are examples of apps with similar issues to the above. I'm pretty new to NixOS, but I'd be happy to contribute in whatever way I can -- testing, etc.
Move on :D
I wonder if this long-standing issue is related
The issue is a breaking ABI . The jack server and the clients have to be compiled against the same toolchain. So if you use a nixos cached client, like zynaddsubfx with a libjack2's jackdbus from nixpkgs cache, you'll get such errors : before : nixos cache /nix/store/7l573r73dqfisf6mjngsyg2xg3dsfvc9-zynaddsubfx-3.0.5/bin/zynaddsubfx after install from nixpkgs : /nix/store/sqb7cjb0gjv503k8nrpqjz0fi11r6qgq-zynaddsubfx-3.0.5/bin/zynaddsubfx
Interesting. I've had no trouble with zynaddsubfx. That's one that's worked for me. How would the gcc version come into play here?

Bignaux Ronan <:
Sorry i didn't investigate more, i'd be interesting if people can fix theirs bugs with that, anyway, time to close this issue.
Yes, when is merged, this can be closed as far as I'm concerned. Thanks !