Need a tagged release for distro support

[alerque]

I'm working at bringing official builds of greetd to the Arch Linux [community] repository. I'll have at least a couple of the most common greeters to go with it but personally this one looks like something I'd want to run. Please consider adding a stable release tag (even a v0.1.0) to match the Cargo file you already have to the Git repository at some known working state. It's pretty hard to package software without some upstream nod to a release point.

[rharish101]

Sure, I'll create a release soon, once I've fixed some of the current issues, and after deciding on some breaking changes.

[rharish101]

I've released 0.1.0. You can find it here: https://github.com/rharish101/ReGreet/releases/tag/0.1.0

[alerque]

Thanks! Given that you posted the VCS packaging to the AUR I'm assuming you use Arch yourself. I'd be glad enough of somebody to test the greetd related packages currently in [community-testing], very shortly to include this.

BTW I invented a minimal config file to include in the packaging, but it would be nice if this was upstreamed. That or the "sample" config should not what are defaults or not and probably have everything commented out so people can add in just what they want to override. If you want a separate issue or PR related to that I can do so later.

[rharish101]

Thanks for being a maintainer!

I'd be glad enough of somebody to test the greetd related packages currently in [community-testing], very shortly to include this.

Sure, I'll test them out and give you feedback when I have time (might need a few days).

BTW I invented a minimal config file to include in the packaging, but it would be nice if this was upstreamed. That or the "sample" config should not what are defaults or not and probably have everything commented out so people can add in just what they want to override.

The sample config is meant to give a headstart for those looking to configure ReGreet, and also serve as documentation for the available options. When it comes to defaults, not every option's default is well known, for example GTK settings (since that depends on what the "default theme" and other defaults are set for the user that ReGreet runs as).

That is why I designed ReGreet to function without any config, and why I've supplied a sample config. Let me know if there's a use case I've missed though.

[alerque]

I had to supply a config by default to get the power commands working because the greetd package I built is defaulting to running as greeter, not root. I guess no other defaults need changing, it just wasn't clear at first which where things than needed to be set to work vs. things users may want to tinker with.

At the moment the package as installed on my test system isn't showing any sessions. Any suggestions there? The default sessions path should be right for Arch...

[rharish101]

I had to supply a config by default to get the power commands working because the greetd package I built is defaulting to running as greeter, not root. I guess no other defaults need changing, it just wasn't clear at first which where things than needed to be set to work vs. things users may want to tinker with.

That's odd; can you run reboot and poweroff without root? They're set as the default power commands in ReGreet, and I can run them without root. Maybe I've configured something on my system that lets me do it...

At the moment the package as installed on my test system isn't showing any sessions. Any suggestions there? The default sessions path should be right for Arch...

Could you attach the log file after running ReGreet with regreet -l debug?

[rharish101]

I'd be glad enough of somebody to test the greetd related packages currently in [community-testing], very shortly to include this.

Sure, I'll test them out and give you feedback when I have time (might need a few days).

I tested it, and here's my feedback:

1. Works great when using Sway, just like the AUR package.
2. When using Cage, I can't seem to view the dropdown menus at all. However, if I start randomly clicking on the sessions list, I am somehow able to select sessions.
3. I am able to reboot and shut down using the buttons, both with and without any default config whatsoever.

I think point 2 explains why you weren't able to see the sessions list. Maybe dropdown menus in GTK4 use a feature that Cage doesn't support, since it works fine on Sway. If it works for you with Sway, then it would be better to remove the dependency on Cage and adding Sway. Since the user has to manually add the greeter command to /etc/greetd/config.toml, maybe the Wayland compositor should be added as an optional dependency - to allow for user choice (for e.g. if someone wants to use Hyprland instead of Sway).

EDIT: Cage works perfectly well, if the latest git commit is used. Since that's on the AUR instead of the main Arch repos, my recommendations as written above still hold.

Point 3, however, is strange, since I'm able to run those commands without superuser access. Could you confirm whether you are able to run reboot and poweroff without root?

[otaj]

Hi @alerque, would it be possible to drop the cage dependency in official Arch package? Since that one is fairly old, and with quite a bit of its problems (such as inability to use kanshi to manage monitors or set up keyboards), the hard dependency to it essentially makes it unusable and instead, I'm using greetd-regreet-git from AUR.

I also noticed that you maintain greetd-gtkgreet, which has the similar architecture (needs to be run in a wayland session), yet you didn't include hard dependency on cage for that package.

Thank you!

[alerque]

I am willing to adjust this, but we do need some kind of compositor dependency. Even with cage as a dependency of course you are welcome to configure it to use any compositor you like, you don't have to use cage at all. But the package should depend on some compositor and Arch doesn't (yet) have any generic provides for "wayland-compositor" or similar. That might be a way forward but I would have to talk a whole bunch of other devs into it. To that end an open bug on the Arch bug tracker about this would be helpful if you want to get the party started.

Not including a compositor in the gtkgreet package was kind of an oversight, although mitigated by that package having transitive dependency on wayland and a whole bunch of other stuff.

[Wunderharke]

I have refrained from installing the package because of the dependencies. Maybe optional dependencies for some compositors could be added instead?