On 2024-09-12 12:03, Pádraig Brady wrote:
This is tricky enough, that we should be as restrictive as possible here,
so I may resort to strspn(f, "0123456789") to parse instead.
I'll think a bit about it.
The code's also assuming INT_MAX < INTMAX_MAX, which POSIX doesn't
require. You could pu
I'm not seeing that false alarm when building coreutils v9.5 on Ubuntu
24.04 LTS with "./configure --enable-gcc-warnings CC=gcc-14".
What GCC version are you using? If it's not GCC 14, try upgrading. I'm
using gcc-14 (Ubuntu 14-20240412-0ubuntu1) 14.0.1 20240412
(experimental) [master r14-9935
I don't see a bug there. 'test' is behaving as documented.
Expectation:
`var=''; [ -n $var ]; echo $?` should NOT return `0`
This expectation is incorrect, because that command should exit with
status 0. This is because the command '[ -n $var ]' is equivalent to:
[ -n ]
which is equivale
installed the attached patch, which fixed things for me, and am
marking the bug as fixed.From bfbb3ec7f798b179d7fa7b42673e068b18048899 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 3 Aug 2024 22:31:20 -0700
Subject: [PATCH] shuf: fix randomness bug
Problem reported by Daniel Carpenter
On 2024-07-21 10:44, Pádraig Brady wrote:
We can just rely on the timestamp of the .tarball-version
to support reproducible _tarballs_.
Although this makes the distributed file contents reproducible, the
tarballs themselves are still not reproducible, since they contain
random timestamps and
On 2024-07-17 02:28, Martin MOKREJŠ wrote:
$ LANG=C sort -k 1 -k 3,3n -r somefile.tsv
It's not a bug, because that 'sort' isn't doing what you think it's
doing. Please try 'sort --debug' to see what's going on.
On 7/10/24 15:12, mark.yagnatin...@barclays.com wrote:
Re: strptime is mistake: you think that particular function is bad
Yes, though I lack the time to go into details right now.
On 7/10/24 13:59, mark.yagnatinsky--- via GNU coreutils Bug Reports wrote:
BSD date has this flag
Unfortunately it uses -f for the flag, and -f already has a
well-established different meaning in GNU 'date'. We could add it to GNU
date under a different (long) option name, though we'd still b
I'm dubious. I've never had much luck with strptime, as in practice it
has its own glitches that are even worse than what 'date' currently
uses. For example, it's dicey in non-C locales, and it mishandles time
zones and daylight saving transitions even in the C locale.
That being said, if some
On 7/10/24 00:35, Pádraig Brady wrote:
OK so id(1) will always show all groups it knows about.
Then the warning message might be along the lines of:
"warning: User '%s' is a member of more groups than the current
system limit"
I also am not seeing the point of the proposed diagnostic. I da
On 7/9/24 03:19, Richard Neill wrote:
IP_JSON=$(curl https://whatsmyip.dev/api/ip)
TS=$(echo $IP_JSON | jq '.ts' -r)
TS=$(echo "$TS/1000" | bc)
DATE=$(date --date @$TS)
This is better, as it saves on subprocesses:
IP_JSON=$(curl https://whatsmyip.dev/api/ip)
TS=$(jq -nr "$IP_JSON|.ts")
DATE=$
On 7/8/24 21:18, Richard Neill wrote:
Also, this is an increasingly common format to see as an input
In shell apps? News to me. I thought it was more of a Java and/or
JavaScript thing. Those languages love ms. POSIX, though, prefers ns.
For occasional use one can just use the shell, with no
7 00:00:00 2001
From: Paul Eggert
Date: Fri, 24 May 2024 08:42:14 -0700
Subject: [PATCH] ls: improve sorting doc
Problem reported by Dan Jaobson (Bug#71171).
* doc/coreutils.texi: Clarify that directory entries are sorted,
not command-line arguments.
* src/ls.c (usage): Be less chatty about -U
On 2024-05-12 04:49, Pádraig Brady wrote:
@@ -1151,7 +1151,8 @@ main (int argc, char **argv)
{
/* Default cp operation. */
x.update = false;
- x.interactive = I_UNSPECIFIED;
+ if (x.interactive != I_ASK_USE
On 2024-05-01 09:32, Art Shelest via GNU coreutils Bug Reports wrote:
Yes, this is the bug.
Will you please fix it?
I don't see a bug here. In the POSIX world, CR is just another character
and 'paste' is required to paste it like it would paste any other character.
As you mentioned, a simpl
behave
similarly, neither should loop: they should both output the requested
number of random bytes. Similarly for /dev/zero. I installed the
attached patch to do that.From fb543b6b82c1f3a20ff88f44cc3ed367bfe811b6 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 19 Apr 2024 21:44:32 -0700
ks.
Also, I am documenting this macOS bug in Gnulib by installing the second
attached patch to Gnulib, and am cc'ing this email to bug-gnulib.From 29345117a4cf85aceb88e3901758b19a4867062e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 19 Apr 2024 00:12:50 -0700
Subject: [PATCH] Fi
On 4/18/24 14:52, Sergei Trofimovich wrote:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fstat.2.html
as
BUGS
Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
except for the blocksize field, and a uniqu
On 4/17/24 03:19, Pádraig Brady wrote:
Patch looks good, and conforms to POSIX.
Thanks for the review. I installed the patch and am closing this bug report.
re orthogonal. GNU ls is an
odd hybrid of 7th Edition and FreeBSD and messes this up.
Rather than document the hybrid mess, let's bite the bullet and fix it.
FreeBSD behavior makes more sense, so let's do that. Proposed patch
attached.From 674a6c262e594102b0485c5ded854c1be5902777 Mo
On 4/16/24 12:44, Pádraig Brady wrote:
A related suggestion was from Marc Chantreux (CC'd)
to support '-' to imply stdin, which would be more portable.
There is some merit to that suggestion too.
I see that merit too, as when 'install' reads from stdin it needn't do
the inode check. However, P
On 4/16/24 07:47, Alejandro Colomar wrote:
Since you couldn't reprodude it in a recent Darwin, maybe it's
just a bug in an old Darwin.
It'd have to be pretty old. As near as I can see from
xnu/bsd/kern/sys_pipe.c, the st_ino field was zero (i.e., not random)
even in xnu-792 dated 2005.
I'd
On 2024-04-08 10:59, Ondrej Mejzlik wrote:
The command uname returns "unknown" on Fedora 38,39 and probably 40.
There is a similar very old bug here which has not been fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905
Indeed there is, and I merged your bug report into that old one. It'd
.
PS. My current little task is to get i18n to work better with 'sort'.
Among other things I want Unicode-style full case folding.From 225cb8d7473eadb481a4884e929bf23589d4bd82 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 6 Apr 2024 15:13:23 -0700
Subject: [PATCH 1/4] =?UTF-8?q?c
On 2024-03-31 12:45, Bruno Haible wrote:
I think you must ask this to yourself:
- What caused you to change the unit tests on 2023-09-04?
- How is the musl version that you used on that date configured?
What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
- Did you wor
On 3/31/24 05:22, Pádraig Brady wrote:
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
https://githu
#x27;s problem, whatever it is.From f130f5426ecd4edd5596797e0a5721b927f80126 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 30 Mar 2024 13:28:01 -0600
Subject: [PATCH] time_r-tests: skip French tests if no Europe/Paris
* tests/test-localtime_r.c (main):
* tests/test-localtime_r-mt.c (main):
If TZ='Europ
On 3/21/24 14:45, Bernhard Voelker wrote:
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
There's another wh
On 3/20/24 15:53, Bernhard Voelker wrote:
$ echo 1 > a
$ mkdir d
$ echo 2 > d/a
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
2
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
On 3/17/24 04:32, Pádraig Brady wrote:
I think the --no-copy situation is brittle, as scripts not using it now
would be atomic, but then if we ever supported cross fs swaps
it may become non atomic. I'd at least doc with a line in the --exchange
description in usage() to say something like:
"U
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.
Yes, that's mv's original sin,
On 3/19/24 08:33, Rafal Maszkowski wrote:
he --debug option advised in
README does not say anything helpful:
(echo a; echo b) | sort --debug -nu
sort: text ordering performed using simple byte comparison
a
^ no match for key
That diagnostic message is helpful. It's telling you that there's no
tomic exchange.From d522aba06107d3532ad6103470727bf9057f8d2c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 16 Mar 2024 22:50:17 -0700
Subject: [PATCH] mv: new option --exchange
* src/copy.h (struct cp_options): New member 'exchange'.
* src/copy.c (copy_internal): Support the
On 2024-03-14 06:03, Pádraig Brady wrote:
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running the program, because (with the "volatile") clang will
error out.
Alternatively perhaps there's
On 2024-03-12 19:24, Grisha Levit wrote:
- AC_COMPILE_IFELSE(
+ AC_RUN_IFELSE(
This sort of change would break cross-compilation, no?
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running
On 2024-03-08 00:49, brian wrote:
Please consider this bug report to be closed. I'm not sure if/how I can
do that via e-mail.
Thanks for following up, and good luck with your hardware or drivers.
Closing the bug report.
On 2024-03-08 05:47, Pádraig Brady wrote:
seq $a | xargs printf -- 'x%.0s'
printf "%${a}s" '' | tr ' ' x
yes x | head -n$a | tr -d '\n'
Oh, I like those! Unfortunately the printf solution silently fails for
me when a=100 due to a bug in Bash. Perhaps I'll get up the
energy
On 3/4/24 12:35, Pádraig Brady wrote:
Another point worth mentioning before changing this,
is that changing would make the --swap operation non symmetric.
I.e. `mv -x a d` would be different to `mv -x d a` where d in a directory.
Yes, of course. It's just like mv without the -x. After you've do
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development version yesterday:
https://github.com/landl
On 3/4/24 15:37, Petr Malat wrote:
Why do you expect this?
I expect it because mv has always treated destination directories that
way. This has been true since the 1970s. We should not change this basic
mode of operation.
To fix this, 'mv -x' should respect the usual mv behavior with resp
On 3/4/24 15:16, Petr Malat wrote:
I prefer KISS principle and allowing
swapping just 2 paths.
In that case, the option should be added to the 'rename' command, not to
'mv'.
It is not KISS to add an option to 'mv' that makes it act completely
differently, such that most of mv's other opti
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardware. For example, if you're using ZFS,
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B' when B is a directory; it renames B to
On 2024-02-20 12:33, Mathias MICHEL via GNU coreutils Bug Reports wrote:
I don't understand why --hide is depending on whether FILEs were provided
or not to the command. This is the opposite of what Paul stated.
It's not the opposite of what I stated. I said that --hide affects only
files that
On 2024-02-18 14:07, Mathias MICHEL via GNU coreutils Bug Reports wrote:
Is it expected that --ignore arg does not apply on globbed FILE ?
Yes. --ignore is about what 'ls' finds in directories, not about
command-line arguments.
My goal is to avoid using grep or complex find args:
> ~/.ssh
Thanks. One minor comment about this:
+@item B
+brain 16 bit float
+@item H
+half precision float
It might be helpful explain these two formats, e.g., to cite:
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
and
https://en.wikipedia.org/wiki/Half-precision_floating-point_format
On 2/1/24 13:59, Pádraig Brady wrote:
bfloat16 looks like a truncated single precision IEEE,
so we should be able to just pad the extra 16 bits with zeros
when converting to single precision internally for processing.
Sounds good. This would mean od could work even the platform doesn't
suppor
Oh, and another thought: suppose someone wants to use od on bfloat16_t
values? They're popular in machine learning applications, and likely
will be more popular than float16_t overall. See:
https://sourceware.org/pipermail/libc-alpha/2024-February/154382.html
Thanks for writing that. One suggestion I'd make is to change this:
#ifndef FLT16_MAX
/* This is just a place-holder to avoid a few '#if' directives.
In this case, the type isn't actually used. */
typedef float _Float16;
#endif
to something like this:
#ifdef FLT16_MAX
typedef _Float1
On 1/31/24 06:06, Pádraig Brady wrote:
To my mind the most protective option takes precedence.
That's not how POSIX works with mv -i and mv -f. The last flag wins. I
assume this is so that people can have aliases or shell scripts that
make -i the default, but you can override by specifying -f
On 2024-01-30 03:18, Pádraig Brady wrote:
So we now have the proposed change as:
- revert -n to old silent success behavior
- document -n as deprecated
- Leave --update=none as is (will be synonymous with -n)
- Provide --update=none-fail to diagnose and exit failure
Thanks, that's
On 1/29/24 08:11, Pádraig Brady wrote:
Right, that's why I'm still leaning towards my proposal in the last mail.
Well, I won't insist on doing nothing; however, the proposal needs
ironing out and now's a good time to do it before installing changes.
- revert to previous exit success -n
On 2024-01-28 05:22, Pádraig Brady wrote:
At this stage it seems best for us go back to the original Linux
behiavor (use case 3),
and to silently deprecate -n in docs to document the portability issues
with it.
I'm not sure reverting would be best. It would introduce more confusion,
and woul
On 2024-01-06 07:34, Pádraig Brady wrote:
Though I'm not seeing this suggestion with GCC 13.2.1,
so perhaps GCC 12 can determine the loops are finite?
I'll apply this since GCC 13 is less that a year old,
but in general we try to avoid littering code like this.
I would not apply this, as it's
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to cp
users. With the newer Coreutils (FreeBSD) behavior, you can reliably
write a script to do something if cp
On 2023-12-15 10:49, Michael Stone wrote:
There's no compelling reason to force this change
Well, certainly nobody compelled us at gunpoint
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that
On 12/11/23 12:03, Abraham S.A.H. via GNU coreutils Bug Reports wrote:
a sane default behaviour regarding extended attributes in mv and others?
What's wrong with the default behavior in current GNU mv? Please give a
specific example (specify platform, filesystems, mv version, etc.).
That's not a bug, in that 'split' is behaving as documented. The first
input line is one byte shorter than the second one. 'Split' divides the
input into two regions, and because the first region happens to be one
byte longer than the second region both input lines are sent to the
first output
On 11/30/23 12:11, Pádraig Brady wrote:
Though that will generally give 128K, which is good when processing all
of a file,
but perhaps overkill when processing just the last part of a file.
The 128 KiB number was computed as being better for apps like 'sed' that
typically read all or most of
On 2023-11-27 08:24, dann frazier wrote:
+ if (fstat (fd, &stats) != 0)
+{
+ error (0, errno, _("cannot fstat %s"), quoteaf (pretty_filename));
+ return false;
+}
+
+ bufsize = ST_BLKSIZE (stats);
If fstat fails, that's no reason to exit. Just use bufsize = BUFSIZ and
keep
Thanks. This is a bug in the glibc regular expression matcher. It's part
of a well known series of bugs. See, for example:
https://sourceware.org/bugzilla/show_bug.cgi?id=12896
https://sourceware.org/bugzilla/show_bug.cgi?id=17356
It's not of much practical concern since the attacker should not
Thanks for the quick fix for the bug I introduced.
behavior is oddball.From f4a59d453ebfa6dcaf2dd1a89a64c1fa05af7a85 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 25 Oct 2023 08:45:15 -0700
Subject: [PATCH 1/3] build: update gnulib submodule to latest
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnuli
On 10/23/23 06:08, Pádraig Brady wrote:
However the default operation should be the
most common requirement (and also the RFC documented operation in this
case).
A similar case I hit very frequently is pasting hex into bc, and it's
very annoying to have to convert to uppercase before doing this
On 10/23/23 12:58, petabaud51 wrote:
Could you folks please add it to 'man expr'?
Man pages are supposed to be terse
I looked at the text version of the bug report and don't understand it.
Can you please rephrase the bug report so that you tell us how you
invoked 'paste' (command line arguments and input file contents), what
behavior you expected, and what behavior you observed? Please bear in
mind that your
0
From: JediWisdomKeeper
To: Paul Eggert
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, October 2nd, 2023 at 6:45 AM, Paul Eggert
wrote:
Would you please resend your bug report as plain text? Thanks.Command used: klee --simplify-sym-indices --write-cvcs --wri
Would you please resend your bug report as plain text? Thanks.
19799/utilities/sort.html#tag_20_119_04From a2434d3e58e8ead6c4c92fd989da32fe648e1545 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 28 Sep 2023 18:02:25 -0700
Subject: [PATCH] sort: improve --help
Problem reported by Jorge Stolfi (bug#66253).
* src/sort.c (usage): Suggest looking at th
On my long list of things to do is to have sort -g sort more
deterministically with NaNs. This could be done with the new totalorder
and totalorderl functions in C23 Annex F.10.12.1, if available. The fix
would not be portable (a these functions are newly sort-of-standardized
and are often not
setxattr.
However it's bad form. And it means coreutils needs the attached
workaround not just for CIFS, but also for ext4 in some (rare) cases.
I installed the attached workaround on coreutils and am closing the bug
report. Thanks again for mentioning it.From 9cd52bd9993163c2ef8b3d62b757c5
On 2023-09-01 19:52, Paul Eggert wrote:
Yes please. If chmod also does not work coreutils might need more
workarounds.
Just to be clear; please try it on a file where chmod should fail
because you don't own the file and you're not root. chmod should fail
with EPERM in this case; i
On 2023-09-01 16:12, Bruno Haible wrote:
Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS
on my system. Should I try it also on a directory inside the CIFS mount?
Yes please. If chmod also does not work coreutils might need more
workarounds.
Good, thanks for confirming that the chmod family does not have a
similar bug.
I installed the attached workaround into coreutils master on Savannah.
Please give it a try.From 5f971361608749e1245c5eb12096de2acd32bf83 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 1 Sep 2023 15:05:21
On 2023-09-01 08:09, Bruno Haible wrote:
It applies to all 4 variants, as can be seen from applying it to a directory:
$ ./a.out /media/nas/bruno/dir1
lchown: Permission denied
fchownat: Permission denied
chown: Permission denied
fchown: Permission denied
Thanks, for coreutils it'd be helpful
Thanks for the followup. I looked into fixing it in Gnulib and it
appears that this would require an extra syscall (or maybe even two) per
file when copying to a CIFS filesystem, which I'd rather avoid. So I'm
leaning more towards working around the bug in coreutils. Before doing
that, it'd be
On 2023-08-31 08:35, Eric Blake wrote:
Typing-wise, %#s as a synonym for %b is
probably going to be easier (less shell escaping needed). Is there
any interest in a patch to coreutils or bash that would add such a
synonym, to make it easier to leave that functionality in place for
POSIX Issue 9 e
On 2023-08-29 11:20, Bruno Haible wrote:
People say that "chown only works for root anyway" [1]
I don't think that is the issue here. fchownat is failing with EACCES,
which is supposed to mean that search permission is denied on a
component of the path prefix, but in Android I guess EACCES al
Thanks for reporting that. I installed the attached patch into Gnulib
and this should appear in the next coreutils release.From 1e6a26f9312bb47e070f94b17b14dc1a6ffbb74f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 30 Aug 2023 18:26:52 -0700
Subject: [PATCH] readutmp: fix core dump if
On 8/22/23 02:58, Osipov, Michael (IN IT IN) wrote:
So no action is required anymore.
Thanks for confirming that. Closing the bug report.
On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug
Reports wrote:
in 9.3 year 2038 support with 64 bit time_t was made required [1], here
on HP-UX this is a bit problematic, but that's not the actual problem.
The diff between 9.2 and 9.3 [2] says how this can be fixed on platform
On 2023-08-15 14:23, Bruno Haible wrote:
The other patch I mentioned, from
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00028.html ,
is also needed, for the "VM saved/sleep" change on NetBSD, OpenBSD, Minix,
as far as I understand.
Also, a typo in NEWS: s/Minux/Minix/
Thanks, I had
On 2023-08-14 00:05, Haoxin Tu wrote:
if the function `fts_read` get a return value of
NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer
`fts->fts_cycle.state` will still keep 0 before the free operation `free
(sp
Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 15 Aug 2023 14:00:54 -0700
Subject: [PATCH 1/2] uptime: be more generous about read_utmp failure
* src/uptime.c (print_uptime): Check for overflow
when computing uptime. Use C99-style decl after statements.
Do not let an idx_t value g
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 patch
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 'up
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. Al
o
Lu, the main developer for Emacs on Android.From cc0a30a876adffa5ec110df9f4e0f21097f6d73e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 9 Aug 2023 12:06:25 -0700
Subject: [PATCH] Adjust to random-seed move
For some time, GNU/Linux systems have put their random-seed file
somewhere other
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
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 bo
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
Alt
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
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 <https://github.com/thkukuk/wtmpdb> that wtmpdb comes
with its own "last". I
On 2023-08-06 13:00, Paul Eggert wrote:
How does "last" emulate /var/log/wtmp using systemd?
Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes
with its own "last". Is the plan to migrate this code into util-linux
"last", or simply to ki
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".
. I installed the
attached to Gnulib.From dcf286c586069684fe4d5bb2bd770394cd7cdad6 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 6 Aug 2023 12:43:05 -0700
Subject: [PATCH] readutmp: fix comment bug ID
* lib/readutmp.c: Fix comment (thanks to Bruno Haible).
---
lib/readutmp.c | 2 +-
1
what I had. So I nstalled the
first ten attached patches into Gnulib, and the last patch into coreutils.
I haven't tested this with the latest systemd so there could well be
typos in that part of the code.From 39a4cb0afdf4f2a1e6c2f3176b84e5b4cfe8996d Mon Sep 17 00:00:00 2001
From: Paul Eggert
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_st
Thanks, I propagated that into Coreutils and installed the simplified
patch I mentioned yesterday. Closing the coreutils bug report.
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).
1 - 100 of 3844 matches
Mail list logo
