On 2025-02-17 03:11:43 +0100, Chris Hofstaedtler wrote:
> * Michael Stone <mst...@debian.org> [250217 02:57]:
> > On Mon, Feb 17, 2025 at 01:32:14AM +0100, Chris Hofstaedtler wrote:
> > > * Vincent Lefevre <vinc...@vinc17.net> [250217 01:20]:
> > > > And what about non-X terminals, such as provided by GNU Screen?
> > [...]
> > >
> > > I can see how they are probably not very interesting. But anyway,
> > > its a question for upstream.
> >
> > No, it's a question for debian. We're releasing a distribution, and we're
> > responsible for the parts and how they go together. Simply shrugging and
> > saying that people are looking for something that isn't interesting is not
> > particularly user-friendly. Can you explain why a phased approach,
> > preserving utmp/wtmp for this release, while deprecating them and
> > introducing an eventual replacement, is not possible *for debian*?
>
> The d-devel discussion was in April 2024:
> https://lists.debian.org/debian-devel/2024/04/msg00406.html
> Back then would have been a good time to evaluate what changes your
> package needs, and/or see what breaks, and follow up with such questions.
> In February 2025 it's a bit late.
Why late? The fact is that utmp is disabled in Debian's systemd,
while it was currently working (2038 is in 13 years; there's no
hurry) and doesn't break anything.
> One argument for not keeping stuff that will break in y2038 for
> trixie is that would make the time_t-64 transition mostly pointless.
No, only utmp is affected.
But actually, I don't understand why it will break in 2038 while
it uses a 64-bit field for the number of seconds:
struct timeval ut_tv; /* Time entry was made */
where
/* A time value that is accurate to the nearest
microsecond but also has a range of years. */
struct timeval
{
#ifdef __USE_TIME64_REDIRECTS
__time64_t tv_sec; /* Seconds. */
__suseconds64_t tv_usec; /* Microseconds. */
#else
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
#endif
};
However...
> If relevant parts of the system don't work after y2038, then we also
> wouldn't have needed the time_t-64 transition. Given that it's done,
> it seems logical to follow through.
>
> --enable-systemd likely improves the current situation. Why not
> enable it now?
If this works as before, then this is OK.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
