A personal Gentoo repository for packages I maintain. It currently contains gui-apps/wayter, a Rust and GTK 4 greeter client for greetd, aimed at Wayland sessions.

Wayter presents the login UI; greetd and the system's PAM stack handle authentication. The package installs the wayter executable and a sample palette. It does not install or configure greetd, PAM, or a compositor, so those need to be set up on the host.

Add the repository

Create /etc/portage/repos.conf/wfalkowski-overlay.conf:

[wfalkowski-overlay]
location = /home/wfalkowski/Git/wfalkowski-overlay
masters = gentoo
priority = 50

Wayter is keyworded ~amd64. Accept that keyword in /etc/portage/package.accept_keywords/wayter:

gui-apps/wayter ~amd64

Review the planned build, then install:

emerge -pv gui-apps/wayter
emerge -av gui-apps/wayter

Portage builds against the host Rust toolchain and GTK 4 with its Wayland backend. The ebuild uses the Gentoo cargo eclass and locked crate versions from the source Cargo.lock; no network access is needed during the build itself.

Palette

The package installs /usr/share/wayter/colors.ini.example. Wayter reads its active palette from ~/.config/wayter/colors.ini, relative to the greeter process's home directory. Copy the example there, then make sure the greeter account can read it. Editing the example under /usr/share won't change the active colors.

Package source and updates

gui-apps/wayter/wayter-0.1.0.ebuild pins the source archive to a specific commit of the Wayter repository. Cargo dependencies are recorded as individual distfiles in CRATES, with checksums in Manifest.

When updating the package, change PV through the ebuild filename and update the pinned source commit and crate list from the matching Cargo.lock. Regenerate the manifest with:

ebuild gui-apps/wayter/wayter-<version>.ebuild manifest

Then inspect the diff and test dependency resolution before committing. Keep the source revision and lockfile in sync; otherwise Portage may fetch a crate set that doesn't match the checked-out application.