From coreutils 9.0 (note the difference between the "second" and "third"
saturdays):
$ src/date --debug -d "first saturday"
date: parsed day part: next/first Sat (day ordinal=1 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start
On 1/5/22 15:25, Dylan Simon wrote:
Hrm, no, with this patch it still fails, but differently (sorry so many
filesystems):
OK, then perhaps someone with a bit more free time will have to look at
it - unless you can propose a patch that passed "make check".
>From Paul Eggert , Wed, Jan 05, 2022 at 03:07:42PM -0800:
> On 1/5/22 14:11, Dylan Simon wrote:
> > Then it will look like this (I'm inferring, haven't actually tried it):
>
> I'm still not quite following, but does the attached patch address the
> problem?
Hrm, no, with this patch it still
On 1/5/22 14:11, Dylan Simon wrote:
Then it will look like this (I'm inferring, haven't actually tried it):
I'm still not quite following, but does the attached patch address the
problem?diff --git a/src/df.c b/src/df.c
index b803fc73b..8a0293ca9 100644
--- a/src/df.c
+++ b/src/df.c
@@ -127,6
On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote:
> $ date -d "first saturday"
> Sat Jan 8 00:00:00 PST 2022
>
> Unless there is some weird definition of "first Saturday", shouldn't this be
> the 1st (New Year's Day)?
Try date --debug.
--
Andreas Schwab,
>From Paul Eggert , Wed, Jan 05, 2022 at 01:05:03PM -0800:
> On 1/5/22 11:27, Dylan Simon wrote:
> > Only adding rows with all known values
> > might make sense but would still break the test (wrong total total instead):
> >
> >if (known_value (iv->total) && known_value (iv->available)) {
> >
On 1/5/22 11:27, Dylan Simon wrote:
Only adding rows with all known values
might make sense but would still break the test (wrong total total instead):
if (known_value (iv->total) && known_value (iv->available)) {
grand_fsu.fsu_files += iv->total;
grand_fsu.fsu_ffree +=
On 1/5/22 00:44, Joerg M. Sigle wrote:
"When this many people consider a thing a bug, then it's a bug whether maintainers
disagree or not."
By that standard it'll be a bug no matter what the maintainers do, since
feelings are strong on both sides of the issue. So by this reasoning,
We have a filesystem that reports statfs f_files = nfiles, f_ffree = -1
(UINTMAX_MAX). (See rationale https://github.com/ceph/ceph/pull/36127)
Unfortunately this breaks df -i --total and in particular the df/total-verify
test fails. Example output:
> df -i --total / /mnt/ceph
Filesystem
(This has been verified to occur with 9.0.)
$ date -d "first saturday"
Sat Jan 8 00:00:00 PST 2022
Unless there is some weird definition of "first Saturday", shouldn't this be
the 1st (New Year's Day)?
Also, I ran this last week (I think on the 29th or the 30th), and it did
On 05/01/2022 08:44, Joerg M. Sigle wrote:
Dear coreutils developers
Thank you very much for your efferts in trying to provide and maintain
fine tools that help millions or billions of users every day.
I'm one who appreciates that (and I try to do something similar as well).
Still, sometimes
Dear coreutils developers
Thank you very much for your efferts in trying to provide and maintain
fine tools that help millions or billions of users every day.
I'm one who appreciates that (and I try to do something similar as well).
Still, sometimes there have been changes introduced over the
12 matches
Mail list logo
