bug#65269: Possible null pointer dereference on the function cycle_check in rm

Hi Paul, Thanks for your quick response. I have tested the latest git version of coreutils again and it seems the bug I reported was gone. However, I found another new *invalid-free *issue which may be induced by the incomplete fix. Please check the bug details below. Here is the stack info

bug#65276: Build failure with gcc < 4.8

Building the current coreutils on GNU/kFreeBSD 7, I get link errors: CCLD src/cksum src/cksum-cksum.o: In function `pclmul_supported': /home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:149: undefined reference to `__builtin_cpu_supports'

bug#65269: Possible null pointer dereference on the function cycle_check in rm

On 2023-08-13 02:32, Haoxin Tu wrote: We have developed a new tool built on top of KLEE (http://klee.github.io/) to automatically test GNU Coreutils-9.0 and found there might be a possible null pointer dereference Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to this

bug#65269: Possible null pointer dereference on the function cycle_check in rm

Hi, We have developed a new tool built on top of KLEE (http://klee.github.io/) to automatically test GNU Coreutils-9.0 and found there might be a possible null pointer dereference in the function cycle_check in cycle_check.c:60 in the util `rm`. Here is the stack info when the error occurs:

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

On 2023-08-12 16:00, Bruno Haible wrote: I see this as a bug. Find attached a fix for this bug. I'll provide a NEWS entry afterwards, that summarizes the changes in coreutils + gnulib on the various platforms. Thanks, this looks good. A NEWS entry would be welcome. Does this mean Gnulib's

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

PS: I wrote: > (print_uptime): Don't read /proc/uptime You might wonder: What is the replacement? Namely, as a fallback (for situations where the current process is running inside a container or jail): - On Linux, the auxiliary function get_linux_boot_time_final_fallback reads the info from

bug#65255: uptime's boot time is inconsistent after VM sleep & resume

On the following platforms: - Linux (that includes glibc-based systems, Alpine Linux, Raspbian), - NetBSD, - Cygwin, - Minix, the "up" duration is inconsistent after the VM in which the OS is running has been 1. put into sleep / saved / pause mode (terminology depends on the

bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> >> errors and errno set to EACCESS. >> > >> > Was this inside Termux, or inside the Emacs app? >> >> Inside the Emacs app. > > Emacs does not have the following in

bug#64937: boot time on Linux

Natanael Copa wrote: > There are machines without RTC (Raspberry PI for example), and in > this case the time stamp may end up to be the same every reboot (if > correctly set up it should save the shutdown time for the reboot and set > time to this on next boot, but there is no guarantee).

bug#64937: boot time on Linux

Po Lu wrote: > >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial > >> errors and errno set to EACCESS. > > > > Was this inside Termux, or inside the Emacs app? > > Inside the Emacs app. Emacs does not have the following in AndroidManifest.xml, which Termux has:

bug#64937: boot time on Linux

Hi, I had a quick look at the thread, and I have a few comments. 1) it is openrc's bootmisc ( https://github.com/OpenRC/openrc/blob/86efc43d0e0d7569f5d2e7a58b8c461ac9f7dae8/init.d/bootmisc.in#L197) that creates /var/run/utmp. There is no guarantee that this exists. You can for example run emacs

bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> errors and errno set to EACCESS. > > Was this inside Termux, or inside the Emacs app? Inside the Emacs app. I'll try Termux soon: maybe the target SDK version is the culprit.

bug#64937: "who" reports funny dates

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

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: boot time on Linux

Po Lu wrote: > Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial > errors and errno set to EACCESS. Was this inside Termux, or inside the Emacs app? Bruno

bug#64937: boot time on Linux

Bruno Haible writes: > I wrote: >> > No, it isn't. The attached file, when compiled and run under Termux (which >> > doesn't have particular permissions), prints e.g.: >> > >> > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660 >> > from sysinfo: 1691616762.329261637 =

bug#64937: "who" reports funny dates

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: boot time on Linux

I wrote: > > No, it isn't. The attached file, when compiled and run under Termux (which > > doesn't have particular permissions), prints e.g.: > > > > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660 > > from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637 > > > >

bug#64937: boot time on Linux

On Thu, 10 Aug 2023 17:38:10 +0800 Po Lu wrote: > Natanael Copa writes: > > > 2) Even if it does exist, there is no guarantee that the timestamp is > > correct. There are machines without RTC (Raspberry PI for example), > > and in this case the time stamp may end up to be the same every reboot

bug#64937: boot time on Linux

Natanael Copa writes: > 2) Even if it does exist, there is no guarantee that the timestamp is > correct. There are machines without RTC (Raspberry PI for example), > and in this case the time stamp may end up to be the same every reboot > (if correctly set up it should save the shutdown time for

bug#64937: boot time on Linux

Paul Eggert writes: > On 2023-08-09 19:14, Po Lu wrote: >> This uses the uptime counter (which also results in an SELinux denial >> for me, but different Android distributions have SELinux policies of >> varying strictness), which cannot establish the precise time the system >> started > > Emacs

bug#64937: boot time on Linux

On 2023-08-09 19:14, Po Lu wrote: This uses the uptime counter (which also results in an SELinux denial for me, but different Android distributions have SELinux policies of varying strictness), which cannot establish the precise time the system started Emacs doesn't need a precise boot time.

bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> > Also, I don't know how Android records boot time so I'll cc this to Po >> > Lu, the main developer for Emacs on Android. >> >> The boot time is off limits to user programs on Android, for security >> reasons. > > No, it isn't. The attached file, when

bug#64937: boot time on Linux

Po Lu wrote: > > Also, I don't know how Android records boot time so I'll cc this to Po > > Lu, the main developer for Emacs on Android. > > The boot time is off limits to user programs on Android, for security > reasons. No, it isn't. The attached file, when compiled and run under Termux (which

bug#64937: boot time on Linux

Paul Eggert writes: > [For those cc'ed, the thread's at .] > > On 2023-08-09 07:29, Bruno Haible wrote: > >> And on Alpine Linux, while /var/run/utmp is empty, its time stamp is >> essentially the boot time. >> The approach used by Emacs, namely to look at the

bug#64937: boot time on Linux

Paul Eggert wrote: > This patch does not address the problem for Alpine, nor I suspect for > Android. I suppose Alpine could use the timestamp of /var/run/utmp (or > is that /run/utmp?) but I don't know how 'configure' would reliably > detect it's being built or cross-built for Alpine. I'll cc

bug#64937: boot time on Linux

I wrote: > So, all approaches that compute the boot time through a subtraction are > going to be wrong in these scenarios. > > The better approach is really to read the boot time from a time stamp — > inside a file such as /var/run/utmp or /var/log/wtmp, or attached to > a file such as >

bug#64937: boot time on Linux

[For those cc'ed, the thread's at .] On 2023-08-09 07:29, Bruno Haible wrote: And on Alpine Linux, while /var/run/utmp is empty, its time stamp is essentially the boot time. The approach used by Emacs, namely to look at the time stamp of /var/run/random-seed,

bug#64937: boot time on Linux

More info about this problem: I wrote > I have a VM running in VirtualBox, that I booted 6 days ago, then "saved" > it (i.e. all the state gets frozen) and resumed it today around 20:30 UTC. > ... > So, both programs show a "boot time" that is just 5 hours ago, at a moment > when > the VM was in

bug#64937: "who" reports funny dates

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#65167: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.10-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65168: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.15-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 5.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65165: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 4.19-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65166: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 5.4-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 5.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65169: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 6.1-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65170: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 6.4-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 6.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#65164: Patch "x86/speculation: Add force option to GDS mitigation" has been added to the 4.14-stable tree

This is a note to let you know that I've just added the patch titled x86/speculation: Add force option to GDS mitigation to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

bug#64937: "who" reports funny dates

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: boot time on Linux

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 Now that I've implemented this method in gnulib's 'readutmp' module and built coreutils with that, I see

bug#64937: "who" reports funny dates

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: ssh sessions in systemd

On Wed, Aug 02, Bruno Haible wrote: > Thorsten Kukuk wrote: > > openssh is really special: it does not need a TTY for all kind of ssh > > sessions, and thus only opens a TTY if needed after creating the > > logind session. Thus the logind session does not contain the TTY > > informations. > >

bug#64937: session leaders pids

Thorsten Kukuk wrote: > > * The pids now refer to the session leader, which is a parent (or ancestor) > > of the process which has allocated the pty. > > Depends on your application. For the majority of applications, which we > evaluated, the PIDs reported by logind were identical to the PID

bug#64937: ssh sessions in systemd

Thorsten Kukuk wrote: > And systemd/logind has a hack to delete this dummy entry, so that a > fallback hack becomes active, which tries to determine the tty in > another way. But this "hack" exists only for the dbus interface, not for > libsystemd... I see some hack in

bug#64937: ssh sessions in systemd

Thorsten Kukuk wrote: > > The only problem with this mapping is for the ut_line row, which > > used to contain, for inbound ssh, the pty device name. It is not easy > > to find the pty name in this situation; at least, none of the systemd > > APIs and /run/systemd/** files that I looked at helped.

bug#65003: pinky's "Idle" column lost the unit

Thanks for reporting that; I installed the attached.From 93e30466ff6eec8a2cd66374e199017763821478 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 2 Aug 2023 06:47:13 -0700 Subject: [PATCH] pinky: fix "d" typo Problem reported by Bruno Haible (bug#65003). * src/pinky.c (idle_string): Fix

bug#64937: "who" reports funny dates

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

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#65003: pinky's "Idle" column lost the unit

I think this may be fixed with https://github.com/coreutils/coreutils/commit/e886b300 Not at a computer to check

bug#65003: pinky's "Idle" column lost the unit

Hi Paul, Two days ago, 'pinky's output looked like this: Login TTY Idle When bruno?seat0? 2023-07-30 11:25 bruno tty2 2d 2023-07-30 11:25 ... Today, it looks like this: Login TTY Idle When bruno?seat0?

bug#64937: "who" reports funny dates

> 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

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#64954: GNU 'uptime' on OpenBSD always prints "0 users"

Thanks, I propagated that into Coreutils and installed the simplified patch I mentioned yesterday. Closing the coreutils bug report.

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

I wrote in : > - Gnulib modules should better provide .h files that can be #included > on any platform. Thus, it's Gnulib's task to provide a readutmp.h > and a read_utmp() function that can also be used on native Windows. Done as

bug#64937: "who" reports funny dates

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#64954: GNU 'uptime' on OpenBSD always prints "0 users"

Paul Eggert wrote: > > I'm fine with the change, but we'll also need to adjust > > the sc_prohibit_always_true_header_tests syntax check in gnulib > > I looked into that but it's such a hassle that I came up with the > attached simpler patch to Coreutils. How about installing it instead? Yes,

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

On 30/07/2023 20:43, Paul Eggert wrote: On 2023-07-30 11:41, Pádraig Brady wrote: I'm fine with the change, but we'll also need to adjust the sc_prohibit_always_true_header_tests syntax check in gnulib I looked into that but it's such a hassle that I came up with the attached simpler patch to

bug#64937: "who" reports funny dates

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#64954: GNU 'uptime' on OpenBSD always prints "0 users"

On 2023-07-30 11:41, Pádraig Brady wrote: I'm fine with the change, but we'll also need to adjust the sc_prohibit_always_true_header_tests syntax check in gnulib I looked into that but it's such a hassle that I came up with the attached simpler patch to Coreutils. How about installing it

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

On 30/07/2023 15:44, Bruno Haible wrote: Hi, GNU coreutils-9.3 'uptime', on OpenBSD 7.2, prints 16:24:53 up 14 days 13:33, 0 users, load average: 0.04, 0.44, 0.59 whereas the OpenBSD /usr/bin/uptime prints 4:24PM up 14 days, 13:33, 1 user, load averages: 0.04, 0.44, 0.59 The utmp

bug#64937: "who" reports funny dates

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

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

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

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

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

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

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,

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

I agree with Paul suggestion for an error message. In any case, Coreutils 5.93 message was better than the current one On Sat, Jul 22, 2023 at 8:37 PM Paul Eggert wrote: > On 2023-07-22 03:19, Pádraig Brady wrote: > > Given the subtleties in this area, > > I'd be reluctant to adjust diagnostics

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

Thanks to both of you. I installed the attached into Savannah master coreutils. It implements the suggestion, except that later I noticed that EMLINK and ETXTBSY can join the throng. At some point it might make sense to scan for other direct or indirect calls to renameat, renameat2, and

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

On 22/07/2023 18:37, Paul Eggert wrote: On 2023-07-22 03:19, Pádraig Brady wrote: Given the subtleties in this area, I'd be reluctant to adjust diagnostics here. I looked into this a bit more. Given "mv dir e" where e/dir is an existing nonempty directory, 7th Edition Unix fails this way:

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

On 2023-07-22 03:19, Pádraig Brady wrote: Given the subtleties in this area, I'd be reluctant to adjust diagnostics here. I looked into this a bit more. Given "mv dir e" where e/dir is an existing nonempty directory, 7th Edition Unix fails this way: mv: e/dir exists Solaris 10 mv fails

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

On 21/07/2023 18:17, Nir Oren wrote: *mv: error message "Directory not empty" is confusing * description: when you try to move a directory to a location already containing a directory with the same name it would just write "mv: cannot move 'A' to 'B': Directory not empty" first, this is

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

*mv: error message "Directory not empty" is confusing * description: when you try to move a directory to a location already containing a directory with the same name it would just write "mv: cannot move 'A' to 'B': Directory not empty" first, this is technically a wrong error message because

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 2023-07-17 10:12, Pádraig Brady wrote: Right. In headers though, the traditional "static inline" idiom Ah, I forgot that it was in system.h. At some point we should have system.h use _GL_INLINE but that can wait.

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 17/07/2023 18:04, Paul Eggert wrote: On 2023-07-17 03:31, Pádraig Brady wrote: static inline void As a general rule, there's no need for 'static inline' in C, as nowadays compilers figure out inlining just fine for static functions and plain 'static' should be good enough. There are

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 2023-07-17 03:31, Pádraig Brady wrote: static inline void As a general rule, there's no need for 'static inline' in C, as nowadays compilers figure out inlining just fine for static functions and plain 'static' should be good enough. There are exceptions but 'write_error' doesn't look

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 17/07/2023 07:35, Bernhard Voelker wrote: On 7/15/23 23:08, Pádraig Brady wrote: The attached patch-set addresses two classes of issue: 1. Doubled error messages upon write errors 2. Continued processing upon write errors (the orig problem reported). Nice work! Patch 1: > ---

<    1   2   3   4   5   6   7   8   9   10   >