[Pkg-freeradius-maintainers] Bug#1094356: freeradius-utils radlast and wtmpdb last incompatible

[John Chittum]

On Fri, Feb 7, 2025 at 7:21 AM John Chittum <john.chittum at canonical.com>
wrote:

>
>
> On Thu, Feb 6, 2025 at 3:33 PM Andrew Bower <andrew at bower.uk> wrote:
>
>> Control: block -1 by 1086559
>>
>> Hi John,
>>
>> On Mon, Jan 27, 2025 at 08:28:02AM -0500, John Chittum wrote:
>> >    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
>>
>> 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!
>>
>
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]


>
> 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.
>
>
I see that 3.2.7 got merged, however a choice was made to keep `radlast`
without a `last` command being available.

>   FreeRADIUS will still write the file using the old format, but there is
>  currently no implementation in Debian which can read it.
>
 > 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 at 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

>
>
>
>>
>> [1] https://salsa.debian.org/debian/sysvinit/-/merge_requests/14
>>
>
>
> --
>
> John Chittum
>
> Engineering Manager, Ubuntu Engineering, Server
>
> Email: john.chittum at canonical.com
>
>
>
>
>

-- 

John Chittum

Engineering Manager, Ubuntu Engineering, Server

Email: john.chittum at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20250220/ecc8a53b/attachment.htm>