Should we file a ticket for this?

The switch to lastlog2 was planned for a while, just, noone actually did it yet because that needs module changes. I can file a ticket, sure. But the old lastlog and lastlog2 are not mutually exclusive, so if we do that switch we don't immediately need to disable old lastlog. Maybe TODO: remove after switch to lastlog2 would have been a better comment...

We had work on lastlog2 in #282337, and it seems our util-linux is new enough to now contain the lastlog2 code (i have not checked whether we enable the build though). I can try how far i get with that, but that is an orthogonal change (should not block this PAM update)

I opened #429075

TODO: wait for #427968

Does anyone even care about linux-pam on musl? Seems like a pretty esoteric use-case to me. I'd want to avoid waiting for the next systemd release (which will takes weeks if not months to land) as the rest of the PR is ready.

Maybe we just disable the logind support for now in pam on musl on since that wasn't present before either and re-enable it once we have the new systemd version.

thats not the issue. Even if things don't work they should still build. systemd is still required on musl, after all.
The patches exist and seem to work fine, so if the conclusion is not to wait then probably this is ready as-is.

I hesitate to say it's a good idea to add patches to systemd to disable something so that some other software can build on a platform systemd doesn't even support.

What I'm thinking is basically something like this to make it build on musl:

index 13e8f55b1f39..21bc5114e38d 100644
--- i/pkgs/by-name/li/linux-pam/package.nix
+++ w/pkgs/by-name/li/linux-pam/package.nix
@@ -66,16 +66,19 @@ stdenv.mkDerivation (finalAttrs: {
     db4
     libxcrypt
   ]
-  ++ lib.optionals stdenv.buildPlatform.isLinux [
-    audit
-    systemdLibs
-  ];
+  ++ lib.optionals stdenv.buildPlatform.isLinux (
+    [
+      audit
+    ]
+    ++ lib.optionals (!stdenv.hostPlatform.isMusl) [
+      systemdLibs
+    ]
+  );

   enableParallelBuilding = true;

   mesonAutoFeatures = "auto";
   mesonFlags = [
-    (lib.mesonEnable "logind" stdenv.buildPlatform.isLinux)
     (lib.mesonEnable "audit" stdenv.buildPlatform.isLinux)
     (lib.mesonEnable "pam_lastlog" (!stdenv.hostPlatform.isMusl)) # TODO: switch to pam_lastlog2, pam_lastlog is deprecated and broken on ml
     (lib.mesonEnable "pam_unix" true)
@@ -87,6 +90,9 @@ stdenv.mkDerivation (finalAttrs: {
     (lib.mesonEnable "nis" false)
     (lib.mesonBool "xtests" false)
     (lib.mesonBool "examples" false)
+  ]
+  ++ lib.optionals (!stdenv.hostPlatform.isMusl) [
+    (lib.mesonEnable "logind" stdenv.buildPlatform.isLinux)
   ];

   doCheck = false; # fails

I'd say we could even get away with not enabling logind at all (for any hostPlatform) because we didn't enable it before and it wasn't even introduced in this release. It was in linux-pam for a while (at least since 1.5.3, see this PR). In a way, you enabling logind here has nothing to do with upgrading the package.

I'm happy with waiting to enable logind support until the next systemd version. But we should get this package bumped asap. This would also allow us to avoid the dance with kbd and systemd entirely.

utmp has to die, and if logind is the replacement, we should enable it. pam was/is unmaintained in nixpkgs, it was long overdue someone actually took a look at it. As it stands, this PR is a full "lets do it properly" PR.
I also don't see the issue with patching in the nspawn toggle: our systemdLibs does not install nspawn anyways, so we might as well not build it either. This does not actually change anything in the package output, so i am not sure what the fuss is about.