bug#64937: "who" reports funny dates

2023-08-10 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Thu, Aug 10, Bruno Haible wrote: > This is merely a warning, and it's already gone after today's refactorings > in Gnulib. To get past it, either remove '-Werror' from the Makefile, or > bootstrap against the current Gnulib: Thanks, I know how to get past it, else I couldn't have tested the

bug#64937: "who" reports funny dates

2023-08-10 Thread Bruno Haible
Thorsten Kukuk wrote: > Not sure how relevant this code still is, but currently I get with this: > > lib/readutmp.c: In function 'get_boot_time_uncached': > lib/readutmp.c:326:35: error: declaration of 'up' shadows a previous local > [-Werror=shadow] > 326 | struct timespec

bug#64937: "who" reports funny dates

2023-08-10 Thread Thorsten Kukuk via GNU coreutils Bug Reports
Hi, currently testing current coreutils git checkout on a utmp/wtmp free machine, looks good so far. Except there is a compile problem with this patch: On Tue, Aug 08, Bruno Haible wrote: > 2023-08-08 Bruno Haible > > readutmp: Get the boot time with higher precision. >

bug#64937: "who" reports funny dates

2023-08-08 Thread Paul Eggert
Thanks, I installed the attached to simplify a bit further. A nice consequence of these recent changes is that we get to remove some pragmas. The first patch is for Gnulib; the other two are for Coreutils.From e14d7e198f96039dbc4fb2118739e6ca1fc4cec6 Mon Sep 17 00:00:00 2001 From: Paul Eggert

bug#64937: "who" reports funny dates

2023-08-08 Thread Paul Eggert
On 2023-08-08 05:24, Thorsten Kukuk wrote: Something emacs needs to get fixed. On musl libc systems like Alpine, you don't have utmp nor wtmp. Yes, as Bruno mentioned, we know of no way to find the boot time on Alpine. When Emacs cannot determine the boot time, it pretends that the system

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
I wrote: > > (2) The readutmp module should use a runtime 'if' rather than a > > compile-time > > #if, in order to dispatch between the systemd backend and the > > file-based > > backend. This patch implements it. 2023-08-08 Bruno Haible readutmp: Use

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
Thorsten Kukuk wrote: > > What API do you suggest we use instead? > > For me clock_gettime works very well: > https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time Indeed, this provides the boot time with a resolution of 1 µsec. Whereas the /proc/uptime approach only

bug#64937: "who" reports funny dates

2023-08-08 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Tue, Aug 08, Robert Pluim wrote: > > On Tue, 8 Aug 2023 14:29:27 +, Thorsten Kukuk said: > Thorsten> Which means tools like who just don't show anything. And emacs > will > Thorsten> never find out the boot time with the current code. > > What API do you suggest we use

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
I wrote: > > (1) The API of the readutmp module should provide unlimited-length > > ut_user, > > ut_host etc. fields always. No more #ifdef UT_USER_SIZE. > > (2) The readutmp module should use a runtime 'if' rather than a > > compile-time > > #if, in order to dispatch

bug#64937: "who" reports funny dates

2023-08-08 Thread Robert Pluim
> On Tue, 08 Aug 2023 18:11:20 +0200, Bruno Haible said: Bruno> Robert Pluim wrote: Thorsten> They don't record at all. Thorsten> Which means tools like who just don't show anything. And emacs will Thorsten> never find out the boot time with the current code. >> >>

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
Robert Pluim wrote: > Thorsten> They don't record at all. > Thorsten> Which means tools like who just don't show anything. And emacs > will > Thorsten> never find out the boot time with the current code. > > What API do you suggest we use instead? musl libc runs only on Linux. On

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
Paul Eggert wrote: > 0006-readutmp-switch-new-struct-to-struct-timespec.patch > @@ -150,12 +150,11 @@ struct gl_utmp > ⎣ ut_addr_v6 [u]int[4] glibc, musl, Android > */ > > -# include > # if !HAVE_DECL_GETUTENT > struct utmp *getutent (void); > # endif > #

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
I wrote on 2023-08-02: > I wrote: > > The proposed patch is attached. > > Oops, I missed a sizeof of the ut_id field. A corrected patch is attached. Oops, this causes a compilation error on OpenBSD: In file included from ../../gllib/readutmp.c:22: ../../gllib/readutmp.h:216:50: error: no member

bug#64937: "who" reports funny dates

2023-08-08 Thread Robert Pluim
> On Tue, 8 Aug 2023 14:29:27 +, Thorsten Kukuk said: Thorsten> On Tue, Aug 08, Bruno Haible wrote: >> Thorsten Kukuk wrote: >> > On musl libc systems like Alpine, >> > you don't have utmp nor wtmp. >> >> But on Alpine Linux, I don't see a systemd nor a logind

bug#64937: "who" reports funny dates

2023-08-08 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Tue, Aug 08, Bruno Haible wrote: > Thorsten Kukuk wrote: > > On musl libc systems like Alpine, > > you don't have utmp nor wtmp. > > But on Alpine Linux, I don't see a systemd nor a logind daemon. > How are logins meant to be recorded on this system? They don't record at all. Which means

bug#64937: "who" reports funny dates

2023-08-08 Thread Bruno Haible
Thorsten Kukuk wrote: > On musl libc systems like Alpine, > you don't have utmp nor wtmp. But on Alpine Linux, I don't see a systemd nor a logind daemon. How are logins meant to be recorded on this system? Bruno

bug#64937: "who" reports funny dates

2023-08-08 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Mon, Aug 07, Paul Eggert wrote: > On 2023-08-07 04:22, Bruno Haible wrote: > > > sooner than later. My guess is that Fedora and Ubuntu/Debian are only > > waiting for 'who' (coreutils) and 'last' (util-linux / wtmpdb) to > > stop accessing these two files. > > It's not just those two

bug#64937: "who" reports funny dates

2023-08-07 Thread Paul Eggert
On 2023-08-07 04:22, Bruno Haible wrote: Since the fact that /var/run/utmp and /var/log/wtmp are world-readable implies that they are world-lockable and thus the DoS bug https://sourceware.org/bugzilla/show_bug.cgi?id=24492 applies, to me it's clear that both utmp and wtmp needs to go away

bug#64937: "who" reports funny dates

2023-08-07 Thread Bruno Haible
Paul Eggert wrote: > Fedora 38 runs > systemd, for example, and it still maintains /var/log/wtmp. Likewise for > Ubuntu 23.04. Well, these are the permissions of these files: /var/run/utmp /var/log/wtmp /var/log/btmpowner Ubuntu 23.04 rw-rw-r--

bug#64937: "who" reports funny dates

2023-08-06 Thread Paul Eggert
On 2023-08-06 14:06, Thorsten Kukuk wrote: SysV Init is gone and the majority does not miss it, and I don't see a reason why "who /var/log/wtmp" needs to stay. I don't want to get into the middle of another systemd vs init battle. But I don't see why this is relevant to that battle. Fedora

bug#64937: "who" reports funny dates

2023-08-06 Thread Paul Eggert
On 2023-08-06 14:10, Thorsten Kukuk wrote: On Sun, Aug 06, Paul Eggert wrote: On 2023-08-06 13:00, Paul Eggert wrote: How does "last" emulate /var/log/wtmp using systemd? Oh, I see from that wtmpdb comes with its own "last". Is the plan to migrate this

bug#64937: "who" reports funny dates

2023-08-06 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Sun, Aug 06, Paul Eggert wrote: > On 2023-08-06 13:00, Paul Eggert wrote: > > > How does "last" emulate /var/log/wtmp using systemd? > > Oh, I see from that wtmpdb comes > with its own "last". Is the plan to migrate this code into util-linux > "last", or

bug#64937: "who" reports funny dates

2023-08-06 Thread Thorsten Kukuk via GNU coreutils Bug Reports
On Sun, Aug 06, Paul Eggert wrote: > On 2023-08-03 23:53, Thorsten Kukuk wrote: > > And yes, "who /var/log/wtmp" will not work with this, too. But is this > > really a required or usefull use case? > > /usr/bin/last can give you the same output. > > Sure, but some people use "who" for

bug#64937: "who" reports funny dates

2023-08-06 Thread Paul Eggert
On 2023-08-06 13:00, Paul Eggert wrote: How does "last" emulate /var/log/wtmp using systemd? Oh, I see from that wtmpdb comes with its own "last". Is the plan to migrate this code into util-linux "last", or simply to kill off util-linux "last"? Similarly

bug#64937: "who" reports funny dates

2023-08-06 Thread Paul Eggert
On 2023-08-03 23:53, Thorsten Kukuk wrote: And yes, "who /var/log/wtmp" will not work with this, too. But is this really a required or usefull use case? /usr/bin/last can give you the same output. Sure, but some people use "who" for that.[1][2][3] This is partly because "who" predates "last".

bug#64937: "who" reports funny dates

2023-08-06 Thread Paul Eggert
On 2023-08-04 04:58, Bruno Haible wrote: The mentioned GCC bug is about a -Wanalyzer-use-after-free false positive. I guess you meanthttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884 or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101778 ? Thanks for catching that. Yes, it should be

bug#64937: "who" reports funny dates

2023-08-04 Thread Bruno Haible
Paul Eggert wrote: > Thanks for doing all that work. I looked into it, and found a problem: a > command like "who /var/log/wtmp" stops working because the systemd > emulation of read_utmp only supports plain "who" (roughly equivalent to > "who /var/run/utmp" on Fedora). Probably the FILE

bug#64937: "who" reports funny dates

2023-08-04 Thread Bruno Haible
Paul Eggert wrote: > 0001-maint-Update-after-gnulib-module-readutmp-changed.patch > +/* Work around , > + triggered by STREQ_LEN with a negative length. */ > +#if 11 <= __GNUC__ > +# pragma GCC diagnostic ignored "-Wstringop-overread" >

bug#64937: "who" reports funny dates

2023-08-04 Thread Thorsten Kukuk via GNU coreutils Bug Reports
Hi, On Fri, Aug 04, Paul Eggert wrote: > Thanks for doing all that work. I looked into it, and found a problem: a > command like "who /var/log/wtmp" stops working because the systemd > emulation of read_utmp only supports plain "who" (rougnly equivalent to > "who /var/run/utmp" on Fedora).

bug#64937: "who" reports funny dates

2023-08-04 Thread Paul Eggert
Thanks for doing all that work. I looked into it, and found a problem: a command like "who /var/log/wtmp" stops working because the systemd emulation of read_utmp only supports plain "who" (rougnly equivalent to "who /var/run/utmp" on Fedora). So I installed it into coreutils, but the default

bug#64937: "who" reports funny dates

2023-08-02 Thread Bruno Haible
I wrote: > The proposed patch is attached. Oops, I missed a sizeof of the ut_id field. A corrected patch is attached. >From 97be578b107e7b87e32e0c3c2d49dc550489415b Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Wed, 2 Aug 2023 01:32:55 +0200 Subject: [PATCH] maint: Update after gnulib

bug#64937: "who" reports funny dates

2023-08-02 Thread Thorsten Kukuk via GNU coreutils Bug Reports
Hi, On Tue, Aug 01, Bruno Haible wrote: > Thorsten Kukuk wrote: > > If you haven't seen yet, I made some time ago a mapping > > between utmp struct entries and libsystemd functions: > > https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md > > Thanks. This is helpful. > > The only

bug#64937: "who" reports funny dates

2023-08-01 Thread Bruno Haible
> Here are the changes I committed in gnulib. And here are the proposed changes for coreutils. Tested on a Fedora Rawhide system, prepared from https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20230729.n.0.iso The

bug#64937: "who" reports funny dates

2023-08-01 Thread Bruno Haible
Thorsten Kukuk wrote: > If you haven't seen yet, I made some time ago a mapping > between utmp struct entries and libsystemd functions: > https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md Thanks. This is helpful. The only problem with this mapping is for the ut_line row, which used

bug#64937: "who" reports funny dates

2023-07-31 Thread Thorsten Kukuk via GNU coreutils Bug Reports
Hi, On Sun, Jul 30, Paul Eggert wrote: > Thorsten's draft coreutils patches > are a bit > long, and I'm hoping we can simplify this by packaging the fix inside > Gnulib (much as we already packaged the fix for not working on >

bug#64937: "who" reports funny dates

2023-07-31 Thread Paul Eggert
On 2023-07-31 00:08, Thorsten Kukuk wrote: 1. you need to extend ut_tv from 32bit time_t to 64bit time_t, or your patch will not survive 2038. Yes, that's the plan. Gnulib's readutmp module already does this, in apps that also use the year2038 or year2038-recommended modules (which most do).

bug#64937: "who" reports funny dates

2023-07-30 Thread Bruno Haible
Paul Eggert wrote: > If I understand that discussion correctly, the idea is to switch from > utmp/utmpx to the systemd interface once systemd 254 comes out. > > As it happens, systemd 254 was published Friday. It's already contained in Fedora Rawhide. > It'd be good to get it working with

bug#64937: "who" reports funny dates

2023-07-30 Thread Paul Eggert
On 2023-07-30 04:02, Pádraig Brady wrote: Yes I think the consensus is to switch away from the utmp API, which was recently discussed at: https://lists.gnu.org/archive/html/coreutils/2023-06/msg00024.html If I understand that discussion correctly, the idea is to switch from utmp/utmpx to the

bug#64937: "who" reports funny dates

2023-07-30 Thread Sven Joachim
On 2023-07-29 17:30 -0700, Paul Eggert wrote: > On 2023-07-29 12:44, Pádraig Brady wrote: >> I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1 >> which is what glibc uses to force the smaller time types. >> However that didn't fix the issue, so I'll need to look a bit more, >> and how to

bug#64937: "who" reports funny dates

2023-07-30 Thread Pádraig Brady
On 30/07/2023 01:30, Paul Eggert wrote: On 2023-07-29 12:44, Pádraig Brady wrote: I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1 which is what glibc uses to force the smaller time types. However that didn't fix the issue, so I'll need to look a bit more, and how to get only utmp

bug#64937: "who" reports funny dates

2023-07-29 Thread Paul Eggert
On 2023-07-29 12:44, Pádraig Brady wrote: I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1 which is what glibc uses to force the smaller time types. However that didn't fix the issue, so I'll need to look a bit more, and how to get only utmp access restricted to 32 bit types. I looked

bug#64937: "who" reports funny dates

2023-07-29 Thread Pádraig Brady
On 29/07/2023 17:41, Sven Joachim wrote: A 32-bit "who" program reports funny login dates: , | $ file src/who | src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2,

bug#64937: "who" reports funny dates

2023-07-29 Thread Sven Joachim
A 32-bit "who" program reports funny login dates: , | $ file src/who | src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0, with debug_info,