On Thu, 2022-06-09 at 10:57 -0700, Jan “Khardix” Staněk wrote:
> I have switched to another tty which was still running agetty,
> logged in and I was sucessfully able to use pinentry; the tty was
> also
> owned by my user.
> 
> So it seems to me that using greetd, I'm not given the ownership of
> the
> tty and that breaks pinentry. I'm not sure whether this is actually a
> bug in greetd, tuigreet or if I have anything else (PAM?)
> misconfigured.

Are you sure this is the cause? Why in the world would pinentry need to
poke at the TTY?

> Would it be possible to have a new wlgreet release?

done

Announcing the release of wlgreet 0.4.

https://git.sr.ht/~kennylevinsen/wlgreet/refs/0.4

---

wlgreet 0.4

This release fixes a wl_output version 4 incompatibility and adds some
color configuration.

Kenny Levinsen (3):
      readme: Add discuss section
      Restrict wl_output to version 3

greetd just runs the requested command-line received from the greeter 
after successful login, and there are no plans to change that.

Some greeters such as QtGreet 
(https://gitlab.com/marcusbritanicus/QtGreet/) read these files. Take a 
look at those and see if greeters like that suit your needs, or 
consider proposing the feature to your greeter of choice. The 
"upstream" greeters are intentionally very simple, but downstream 
greeters can do whatever they like as long as they implement the greetd 
IPC protocol properly.

Best regards,
Kenny Levinsen

Announcing the release of seatd 0.7.0.

https://git.sr.ht/~kennylevinsen/seatd/refs/0.7.0

---

seatd 0.7.0

This release contains 36 changes from 3 contributors.

Some highlights of this release are:
- Support for NetBSD and wscons devices
- Fix for a polling bug in the logind libseat backend

Well, I can reproduce your issue without the patch by temporarily 
changing my timezone to GMT+10 (TZ=":Etc/GMT+10"), and the branch does 
fix it. It's merged to master now.

I tested as follows after activating the compile-time super-realtime 
debug mode (can't be bothered to wait 24 hours when testing things):

   TZ=":Etc/GMT+10" ./build/wlsunset -S 6:00 -s 20:00 -d 3600 -t 2800

Just specify what the time would be in UTC-land - if you want sunrise 
at 6AM your time, and you're in UTC+4, you say 2AM instead.

It's a little clumsy, but it'll take a bit before I have time to look 
at fixing the manual time input. Automatic calculation using 
latitude/longitude is the primary way to use wlsunset.

This could be a timezone issue. Can you try to input the time as UTC?

wlsunset operates entirely in UTC internally to normalize time against 
orbit calculations, but as a side-effect the manual time input is 
currently also UTC. It's a little annoying to fix in a portable way 
(i.e. works both on Linux and FreeBSD), so I haven't looked at it yet.

I reworked this on top of our new NetBSD support, and it seems like 
we're getting somewhere: https://builds.sr.ht/~kennylevinsen/job/726204

No idea what that EBUSY is about though. I guess I'll have to read some 
OpenBSD kernel source...

Ah, indeed the NetBSD implementation messed up keyboard handling on 
FreeBSD. Nice find!

I applied the fix to master, sorry for the inconvenience.