Add glib and libsecret as dependencies for builds that might need them.
Replace `autoPatchelfIgnoreMissingDeps = true` with an explicit list of
the dependencies we're deliberately ignoring.
GitHub Copilot CLI isn't an open source tool and the documentation isn't
clear on what each possible dependency is used for. I expect some
dependencies are only used in rare scenarios or would never be used by
the CLI tool and are just inhereted from some of the desktop Copilot
applications. That means there's a bit of a guessing game in balancing
(a) the desire to provide all the tools Copilot might use and (b) not
growing the package closure for no real benefit.
I've added glib and libsecret as I don't think they significantly expand
the closure and are relatively likely to be useful. I've left out the
tools that seem most useful for GUI and media interfaces as they're
bulky and seem likely to be included because they're common with
GUI-based Copilot tools rather than because they're needed for GitHub
Copilot CLI.
Assisted-by: GitHub Copilot CLI (claude-sonnet-4.6)
debsGrouped was a nested array, like `[ [ drv1 drv2 ] [ drv3 ] ... ]`.
that doesn't map to any bash item, so it would live only in the json attrs.
the `for component in "${debsGrouped[@]}"; ...` part of buildCommand
was thus referring to an unset variable... but the default bash behavior
is to treat that as an empty array even with `set -u` so the loop was
just doing nothing.
instead, flatten the array on the nix side. bash gets something like
`("drv1 drv2" "drv3" ...)` and the existing shell code destructures
that as expected.
verify by building a vm (e.g.
`tests.vmTools.buildPatchelfInDebian.diskImage`) and checking the
nix-log before and after for `INSTALLING COMPONENT` messages.
Co-Authored-By: Stefan Frijters <sfrijters@gmail.com>
Since e73170e38a, we no longer patch
systemd to prevent it resetting `PATH` for generators. Generators that
depended on this deviating behavior will no longer work, which
ironically includes the upstream `systemd-xdg-autostart-generator`.
Previously, generators would see systemd's actual environment, which
included environment variables set for the PAM session like `PATH`. To
preserve the old behavior *exactly*, we'd really want to be
replicating exactly what the `systemd-user` PAM service sets up, which
could technically include things other than just what we put in
`/etc/pam/environment`. But this is arguably a systemd bug (either
because `systemd-xdg-autostart-generator` shouldn't use the
generator's `PATH`, or because systemd should pass along the `PATH` it
got from PAM), so for now, we can keep it simple and fix it by
replicating what `/etc/pam/environment` does in `/etc/environment.d`.
Adam Dinwoodie