Re: 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 38

Re: 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 co

Re: Shallow git update in bootstrap

Hi, On 06 Aug 2023 at 16:56:45, Bruno Haible wrote: > Carles Pina i Estany wrote: > > When I say "long time" (and data transmission) in my case it's 9 > > minutes: > > - > > carles@pinux:[master]~/git/wget2$ time git submodule update --init > > Cloning into '/home/carles/git/wget2/gnulib'.

Re: 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

Re: 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 that.[1][2]

Re: 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

Re: 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".

Re: 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 110884.

Re: bug#64937: "who" reports funny dates

On 2023-08-04 05:52, Bruno Haible wrote: This code is meant to be multithread-safe. Thanks for fixing that, I hadn't realized it was supposed to be thread-safe (thread-safety is not needed for Coreutils). Making the variables volatile is a win for multithreaded apps. Although the resulting

[PATCH] Document Android, OpenBSD printf "%n" lack

In doc/posix/functions/*printf*.texi, document that the POSIX-specified printf functions do not support the %n format on Android and OpenBSD. This lack of support is deliberate, as %n is a common target of attacks on security. --- doc/posix-functions/dprintf.texi | 2 +- doc/posix-functions/fpri

Re: Shallow git update in bootstrap

> However, --depth=1 has the problem ... Another problem of --depth=1 is that it may fail with git versions < 2.8: https://jira.mariadb.org/browse/MDEV-28032?workflowName=MariaDB+v4&stepId=1 https://github.com/git/git/commit/fb43e31f2b43076e7a30c9cd00d024 Therefore, it's not OK to use --depth=1 b

Re: Shallow git update in bootstrap

Carles Pina i Estany wrote: > Actually, the first time I wondered if the connection or something else > failed. The latter is a user mistake, since there was a message "Cloning into '/home/carles/git/wget2/gnulib'..." and the "..." tells that it may take some time. > When I say "long time" (and d

Re: Android port

Bruno Haible writes: > 1) It's a security problem if a program's binary (+ associated shared > libraries) >somewhere implements a printf with %n, even without actively using it. >Because an attacker can piece together a format string in memory and call >that printf function; this the

Re: Android port

[Redirecting to bug-gnulib. This discussion has nothing to do with Emacs any more.] I wrote: > > Rationale: I cannot guarantee that Gnulib will be able to support %n > > in the long run. The "security-aware community" are filing CVEs here and > > there; %n is among their targets (it has already be

Re: Shallow git update in bootstrap

On 8/6/23 00:25, Carles Pina i Estany wrote: When I say "long time" (and data transmission) in my case it's 9 minutes: - carles@pinux:[master]~/git/wget2$ time git submodule update --init Cloning into '/home/carles/git/wget2/gnulib'... Submodule path 'gnulib': checked out '2ae6faf9c78384dc6