Hi Mark,

On Mon, Jul 28, 2025 at 11:42:19AM +0100, Mark Hindley wrote:
> Thanks for this. You have been folowwing this area more closely than me.

Unfortunately I haven't been on top of the utmp or lastlog side of this
transition even though I did adopt wtmpdb with a view to mitigating user
experiences with that change.

> I believe the original impetus to remove libsystemd linkage from procps
> was to reduce libsystemd infiltration into 'core' utilities.

I am all in favour of that ambition. I don't think the key
building-block packages should depend on libsystemd, hence my
disappointment when coreutils recently gained the dependency (should we
be forking that?)

> Devuan systems without elogind are viable (I use sway/seatd as my daily
> driver) so just adding elogind support to procps isn't a universal
> solution.

Does sway/seatd write to utmp? Does it do anything else?

> Do you have a suggestion or idea as to a way forward?

I see we have forked util-linux, so one thing we could do is to fix the
build of login(1) to restore writing to utmp, for virtual console
logins. That assumes that this is what has actually been broken - I
haven't checked yet.

I think that still leaves session manager entries missing (I seem to get
one for Debian/lightdm but not Devuan/slim). openssh seems to behave
well with regard to utmp.

If we are going to make continued use of utmp we should really try to
sort out any packages that don't realise struct utmp now has unsigned
seconds (converts the y1901/y2038 problem into a y1969/y2160 problem),
but that's not immediately practical. (IMO that would have been a better
use of Debian development time than excising "legacy" usage, which could
have waited another release cycle while the replacements proved and
improved themselves...)

Now, is there anything we can do with elogind-captured sessions without
linking with libsystemd0? Well, maybe... I'm thinking about options! But
to be honest, probably not in time for Excalibur.

Andrew