On Thu, 3 Apr 2025 at 09:47, Marco d'Itri wrote:
> On Apr 02, Bill Allombert wrote:
>
> >Does that breaks the usual unix commands like 'who' ? If yes this is
> who(1) specifically, yes.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 .
> Maybe the coreutils maintainer is already
On Apr 02, Bill Allombert wrote:
Does that breaks the usual unix commands like 'who' ? If yes this is
who(1) specifically, yes.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 .
Maybe the coreutils maintainer is already working to backport this
simple patch in time for trixie, o
Hello Andrew,
On 4/4/25 11:13 PM, Andrew Bower wrote:
On Fri, Apr 04, 2025 at 09:10:42PM +0200, Dirk Lehmann wrote:
On 4/3/25 2:58 PM, Antonio Terceiro wrote:
I never cared about /run/utmp in itself, but I got used to last(1).
FWIW, a new implementation of last is now provided by wtmpdb.
+1
On Wed, Apr 02, 2025 at 05:52:13PM +1100, Craig Small wrote:
Yes, there is definitely a Y2038 issue
*for trixie*?
there are also issues with utmp not
being
handled consistently and some security issues around who can do what to the
file.
Stuff that has been true literally decades. If someon
Hi Dirk,
On Fri, Apr 04, 2025 at 09:10:42PM +0200, Dirk Lehmann wrote:
> On 4/3/25 2:58 PM, Antonio Terceiro wrote:
> > I never cared about /run/utmp in itself, but I got used to last(1).
> > FWIW, a new implementation of last is now provided by wtmpdb.
>
> +1
>
> great, it looks like that
>
>
On Fri, Apr 04, 2025 at 09:10:42PM +0200, Dirk Lehmann wrote:
On 4/3/25 2:58 PM, Antonio Terceiro wrote:
I never cared about /run/utmp in itself, but I got used to last(1).
FWIW, a new implementation of last is now provided by wtmpdb.
+1
great, it looks like that
* wtmpdb(8)
could be a wel
On 4/3/25 2:58 PM, Antonio Terceiro wrote:
On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote:
/run/utmp is no longer provided in trixie, which means that the mechanisms
used to show active sessions in unix for several decades no longer work.
There's a replacement mechanism provided b
On Thu, Apr 03, 2025 at 12:47:07AM +0200, Marco d'Itri wrote:
On Apr 02, Bill Allombert wrote:
Does that breaks the usual unix commands like 'who' ? If yes this is
who(1) specifically, yes.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 .
Maybe the coreutils maintainer is alrea
On Fri, Apr 04, 2025 at 03:43:03PM +0200, Marc Haber wrote:
Can your package handle the classic on-disk format when it is compiled
with 64 bit time_t? I remember there was some discussion about that
back then.
If you touch /run/utmp you'll see it is still working fine with any
packages that ha
On Thu, 3 Apr 2025 17:41:46 -0400, Michael Stone
wrote:
>On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote:
>>On Apr 03, Michael Stone wrote:
>>>The issue isn't making a change, the issue is what change is the
>>>right thing to do. IMO, dropping utmp without any kind of a
>>>transiti
Michael Stone writes:
> I'm the one who gets the complaints that who isn't working right, and
> there isn't a solution to that problem, since the systemd facility
> doesn't provide the same information. I'd argue that a lot of people
> didn't realize how screwed up things were going to be, becaus
On Fri, 4 Apr 2025 at 10:16, Michael Biebl wrote:
> michael@mars:~$ loginctl
> SESSION UID USERSEAT LEADER CLASS TTY IDLE SINCE
>3 1000 michael seat0 2116 usertty1 no -
>4 1000 michael - 2125 manager -no -
>
> 2 sessions listed.
>
> michael@mars:~$ who
On Fri, Apr 04, 2025 at 12:46:03AM +0200, Chris Hofstaedtler wrote:
But the thing that needs looking at is why who in Debian behaves like
it does, and if it doesn't work right, fix that in who or wherever
else it needs fixing in the stack.
Because I haven't turned it on, because I'm really unh
On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote:
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the
right thing to do. IMO, dropping utmp without any kind of a
transition or deprecation period is the wrong thing to do. Hence
this thre
On Fri, 4 Apr 2025 at 09:46, Chris Hofstaedtler wrote:
> Maybe it needs some additional work to fully function
> with current systemd versions. IIRC procps also only recently added
> some new code to deal with new systemd behaviours.
>
That's right, we were counting sessions, not user sessions.
Am 04.04.25 um 00:46 schrieb Chris Hofstaedtler:
Maybe it needs some additional work to fully function with current
systemd versions. IIRC procps also only recently added some new code to
deal with new systemd behaviours.
Maybe try the attached patch. With it applied I get:
michael@mars:~$
* Michael Stone [250403 23:42]:
On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote:
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the
right thing to do. IMO, dropping utmp without any kind of a
transition or deprecation period is the w
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the right
thing to do. IMO, dropping utmp without any kind of a transition or
deprecation period is the wrong thing to do. Hence this thread.
I think it's a bit late now to disagree with the plan imple
On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote:
> /run/utmp is no longer provided in trixie, which means that the mechanisms
> used to show active sessions in unix for several decades no longer work.
> There's a replacement mechanism provided by systemd, but it's not 1:1. I
> propose
Le Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone a écrit :
> /run/utmp is no longer provided in trixie, which means that the mechanisms
> used to show active sessions in unix for several decades no longer work.
> There's a replacement mechanism provided by systemd, but it's not 1:1. I
> prop
Hi,
On Wed, 2 Apr 2025 at 06:27, Michael Stone wrote:
> /run/utmp is no longer provided in trixie, which means that the
> mechanisms used to show active sessions in unix for several decades no
> longer work. There's a replacement mechanism provided by systemd, but
> it's not 1:1.
I'm the procps
21 matches
Mail list logo
