freeradius:src 3.2.6+dfsg-3 contains the following control change:

  [ Arnaud Rebillout ]
  * freeradius-utils: add wtmpdb needed for radlast

`wtmpdb:last` only operates with `wtpmdb` implementation, reading an sqlite
database with a `wtpm` table. freeradius writes a `utmp` struct file.
running `radlast` results in:

$ radlast
wtmpdb_read_all: SQL error: no such table: wtmp

the old `last` was removed from util-linux for not being 2038 compliant.
`glibc` has made the `utmp` seconds uint, so it's safe for additional time.
`wtmpdb` has not implemented a method for reading the old file, nor
migrating data. see GH issue

https://github.com/thkukuk/wtmpdb/issues/14

filed a bug in Ubuntu to revert the control change, but Ubuntu is similarly
without a `last` command in devel:

https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/2096611

The bug contains some discussion about possibly splitting the package more
or even removing the functionality entirely.

libc6=2.40-6

Hi John,

As you note, the wtmpdb upstream hasn't prioritised providing an importer for
utmp-formatted wtmp logs, doesn't expect to, and even if they did, I don't know
if it would be in a form convenient for the purposes of this test.

One option could be to restore the tools in an optional package specifically
for reading legacy files rather than live system administration - e.g. my
merge request on src:sysvinit[1], although I note you have a simpler solution
in mind for freeradius!

[1] https://salsa.debian.org/debian/sysvinit/-/merge_requests/14

freeradius upstream has pushed a change to make building and including
`radlast` as optional

https://github.com/FreeRADIUS/freeradius-server/releases/tag/release_3_2_7

relevant commit:

https://github.com/FreeRADIUS/freeradius-server/commit/fece06e2f4984a1f4c227ba9ef3edf4a8ad5e2ee

if Debian wishes to move to 3.2.7 before freeze, we could remove the
`wtpmdb` dependency.
If you believe `radlast` is important, package splitting makes sense, but
we'll also need a `last` command
provided, and I'm unsure what to suggest as a replacement.

On Fri, Feb 7, 2025 at 7:21 AM John Chittum <john.chittum@canonical.com> wrote:
I see this merge is still open, so no `last` command in Debian sid still.
And thank you for the
discussion in util-linux[0]
I see that 3.2.7 got merged, however a choice was made to keep `radlast`
without a `last` command being available.
 > For now we install the radlast wrapper script, but it will not work
 > until the last implementation in Debian can read those old-formatted
 > files. See Bug#1094356 and Bug#1095490 for details.
 > -- Bernhard Schmidt <berni@debian.org>  Mon, 10 Feb 2025 23:01:18 +0100

as of 3 weeks ago, upstream has removed a bunch of tools[1]

I know it's late in the cycle, and I don't know when the next FreeRADIUS
release will happen. short-term, it may
be worth dropping usr/bin/radlast from d/freeradius-utils.install . This
has already happened upstream
in the linked commit. On the Ubuntu side, with FF for 25.04 Plucky Puffin
happening right now, we are likely
to take this approach, rather than shipping a utility which will return
`not found`

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095490

[1]
https://github.com/FreeRADIUS/freeradius-server/commit/b0f4123c84a0aeaa6fc393fd5e6fdaa0e0a86eaf

Hi FreeRADIUS maintainers,

I attach a patch that might allow radlast to function in trixie by
importing the wtmp file to a temporary wtmpdb database.

Perhaps this could be accompanied by a NEWS entry advising users that
this is a transitionary solution for trixie giving them plenty of time
to sort out a replacement solution.

I am afraid I cannot confirm that this works for FreeRADIUS
specifically but would be happy to help out with any issues.

Andrew