fix(build): libpam fallback detection for Debian - #714
Conversation
5ed1f64 to
a64ab94
Compare
JimmyCozza
left a comment
There was a problem hiding this comment.
@shuber2 Thanks for finding this.
I do have 1 question about this for you. Now that dependency() is called with required:false, does -Dpam=disabled still turn PAM off where pam.pc does exist? I would just like to make sure that we keep that path working for anyone who locks with swaylock and don't want libpam linked into the compositor.
Upstream PAM ships no pam.pc or CMake config, so availability of pkg-config detection depends on the distribution. For instance, Debian does not ship it, so pam is not detected by the Meson build, although it is available. Implement a fallback mechanism by detecting the header file along with the library. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
a64ab94 to
10208d2
Compare
|
I was just about to write why the logic is correct, until I saw it was not. Oh man, three-valued logic fail. Anyway, I took the opportunity to add some comment on the intended logic and reorganized the case distinction. Now it is evident that Sorry I did not realize right ahead. |
JimmyCozza
left a comment
There was a problem hiding this comment.
Looks great!
Thanks @shuber2
Description
The lockscreen did not work on Debian machines. The reason was that meson would not find pam, although the pam dev package was installed. However, upstream PAM does not ship pkg-config files, and so it depends on the distro to ship one. Debian does not. Hence, we need a fallback mechanism here.
Test Plan
Manual test on Debian. Confirmed on Debian Trixie on two different machines.
AI Usage
Debugged and implemented with the help of Claude.
Checklist
lua/awful/,lua/gears/,lua/wibox/,lua/naughty/) are not modified — if a bug surfaces in Lua, the fix belongs in Cmake test-unit && make test-integration)