Submission checklist
Feature type
Packaging / NixOS module
Feature summary
Add upstream-maintained GNU Guix packaging for Noctalia Greeter, which similar to the official Guix support already provided by the main Noctalia repository, so that the repository could be used directly as a Guix channel and expose a noctalia-greeter or noctalia-greeter-git package.
Motivation / use case
Noctalia itself already provides official GNU Guix support, but Noctalia Greeter currently does not.
Guix System already provides greetd-service-type, so once the greeter package is available, users can integrate it declaratively with the existing greetd service rather than relying on the distro-oriented setup scripts.
Having the package definition maintained upstream would also keep the build dependencies and any Guix-specific source adjustments in sync with Noctalia Greeter releases.
Proposed solution
A minimal first implementation could follow the same approach as Noctalia's existing noctalia.scm:
- add a noctalia-greeter.scm Guix package definition;
- make the repository usable as a Guix channel;
- build with meson-build-system;
- use the corresponding Guix packages for wlroots 0.20, Wayland, Cairo, Pango, Fontconfig, tomlplusplus, nlohmann-json, etc.;
- apply any Guix-specific adjustments required for store paths or script shebangs.
Full Guix System service integration does not necessarily need to be part of the initial implementation. Guix already provides a native greetd service, so downstream configurations can use the packaged noctalia-greeter-session as the greetd session command.
If desired later, a small Guix service module could additionally manage the greeter state directory, declarative greeter.toml, PAM integration and optional Polkit appearance sync.
Alternatives considered
No response
References / related projects
No response
Additional context
Thanks a lot for all the developers! Looking forward to your reply!
Submission checklist
Feature type
Packaging / NixOS module
Feature summary
Add upstream-maintained GNU Guix packaging for Noctalia Greeter, which similar to the official Guix support already provided by the main Noctalia repository, so that the repository could be used directly as a Guix channel and expose a noctalia-greeter or noctalia-greeter-git package.
Motivation / use case
Noctalia itself already provides official GNU Guix support, but Noctalia Greeter currently does not.
Guix System already provides
greetd-service-type,so once the greeter package is available, users can integrate it declaratively with the existing greetd service rather than relying on the distro-oriented setup scripts.Having the package definition maintained upstream would also keep the build dependencies and any Guix-specific source adjustments in sync with Noctalia Greeter releases.
Proposed solution
A minimal first implementation could follow the same approach as Noctalia's existing noctalia.scm:
Full Guix System service integration does not necessarily need to be part of the initial implementation. Guix already provides a native greetd service, so downstream configurations can use the packaged noctalia-greeter-session as the greetd session command.
If desired later, a small Guix service module could additionally manage the greeter state directory, declarative greeter.toml, PAM integration and optional Polkit appearance sync.
Alternatives considered
No response
References / related projects
No response
Additional context
Thanks a lot for all the developers! Looking forward to your reply!