bug#35275: spelling mistake manual pages

[Eric Blake]

tag 35275 notabug
thanks

On 4/14/19 7:22 AM, Vikas Talan wrote:
> Dear Sir/Mam,
> I found a spelling mistake in the manual pages. The topic is "22.2 LIMITING
> RESOURCE USAGE" and the spelling mistake is "may". It should be "MANY".
> Kindly check this and make it correct.

Attaching a 2M picture of a screenshot and spamming multiple lists at
once puts unnecessary load on the mail servers as it must fan that out
to all list recipients, even where it is not relevant. Please don't do
that in the future, when a text paste to a single targeted list is
sufficient and much more bandwidth-friendly.

The sentence is from the glibc info pages. And the text is correct as
written. It is talking about a single call that "may fail", not "many
failures" of multiple calls.  I am replying solely to the coreutils list
to drop the bug from the coreutils database, rather than spamming all
the other lists mentioned in your original mail (if it HAD been a bug,
the glibc manual also mentions that you should report bugs in the manual
to https://sourceware.org/bugzilla, or at a bare minimum the libc
mailing list - which I did not see in your scattershot report).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#35275: spelling mistake manual pages

[Paul Eggert]

That report appears to be about the glibc manual. Please report glibc bugs as 
described here:


https://sourceware.org/glibc/wiki/FilingBugs

Also, please use plain text rather than images to describe bugs in a text file.

bug#35275: spelling mistake manual pages

[Paul Eggert]

Eric Blake wrote:

Attaching a 2M picture of a screenshot and spamming multiple lists at
once puts unnecessary load on the mail servers as it must fan that out
to all list recipients


By the way my first thought when seeing a bug report like this, is that it is an 
attempt to break into developers' systems by sending a carefully-crafted image 
designed to exploit a bug in a popular image library. Perhaps I'm being too 
paranoid, but you never know. (Next time, I think I may just ignore or close the 
bug report without looking at the image. :-)

bug#35289: date+%-Y -d "- N years" errors when N > 111

[O. Emmerson]

I have been using 'date +%-Y -d "- 2010 years" in a script for years but
today after using the script after upgrading to Ubuntu 19.04 it has failed.

After some experimentation it succeeds with upto 111 years but fails
from 112 onwards.

Error given is:

'date: invalid date '- 112 years'.


DistroRelease: Ubuntu 19.04
Package: coreutils 8.30-1ubuntu1

I have already reported the bug in Ubuntu
(https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1824688) but
they have advised me to report it here.

Regards

O. Emmerson

bug#35289: date+%-Y -d "- N years" errors when N > 111

[Paul Eggert]

On 4/15/19 7:57 AM, O. Emmerson wrote:
> I have been using 'date +%-Y -d "- 2010 years" in a script for years but
> today after using the script after upgrading to Ubuntu 19.04 it has
> failed. 

It works for me with coreutils 8.31 on RHEL 7 x86-64:

$ date +%-Y -d "- 2010 years"
9

Most likely you are running on a 32-bit machine, and dates in the year 9
cannot be represented in a 32-bit timestamp. So a simple fix would be
for you to switch to a 64-bit machine.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

On 15/04/2019 17:02, GNU bug Tracking System wrote:

It works for me with coreutils 8.31 on RHEL 7 x86-64:

$ date +%-Y -d "- 2010 years"
9

Most likely you are running on a 32-bit machine, and dates in the year 9
cannot be represented in a 32-bit timestamp. So a simple fix would be
for you to switch to a 64-bit machine.


I am running a 64bit version of Ubuntu.
Anyway, as I said, I have been running this command successfully for
years until now.

Here is the full system info from reportbug copied from by original bug
on Ubuntu's tracker:

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: coreutils 8.30-1ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-11.12-generic 5.0.6
Uname: Linux 5.0.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Sun Apr 14 10:59:36 2019
InstallationDate: Installed on 2017-10-08 (553 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64
(20170215.2)
SourcePackage: coreutils
UpgradeStatus: Upgraded to disco on 2019-04-13 (1 days ago)

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

I have downloaded and compiled 8.31 from source to see if it makes any
difference and have gotten the same error.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

$ file /bin/date
/bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
stripped

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

I have ran a few tests on Ubuntu 16.04, 18.04, 18.10, and 19.04 (all X86_64):

16.04:

root@u1604:~# date +%-Y -d '- 2010 years'
9
root@u1604:~# date --version
date (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.04:

root@bionic:~# date +%-Y -d '- 2010 years'
9
root@bionic:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.10:

root@u1810:~# date +%-Y -d '- 2010 years'
9
root@u1810:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

19.04:

cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Interestingly, it is also failing on git head:

130 cerdea@piatam:/data/buildd/coreutils$ src/date +%-Y -d '- 2010 years'
src/date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ src/date --version
date (GNU coreutils) 8.31.12-6d78a
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson  wrote:
>
> $ file /bin/date
> /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
> stripped
>
>
>
>


-- 
..hggdh..

bug#35291: [PATCH] split: fix incorrect suffix length computation

[Johannes Altmanninger]

* src/split.c (set_suffix_length): suffix_needed is now computed
to be the equivalent of ceil(log(n_units_end) / log(alphabet_len)).
Previously, it would give the floor of above logarithm if the number
of units is divisible by the length of the alphabet.
* tests/split/suffix-auto-length.sh: Add test demonstrating the problem.
---

Hi,

This should be a fairly straightforward fix.  It seems like it has been
discovered in 2015 [1] (look for "multiple of 10") but the bug fixed at that
time was a different one. I am not aware of any open bug for this.

Let me know if I am missing something.

Thanks,
Johannes

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20511

 src/split.c   | 11 ++-
 tests/split/suffix-auto-length.sh |  4 
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/split.c b/src/split.c
index 30fdb4462..22b645fc9 100644
--- a/src/split.c
+++ b/src/split.c
@@ -191,13 +191,14 @@ set_suffix_length (uintmax_t n_units, enum Split_type 
split_type)
   if (n_start < n_units)
 n_units_end += n_start;
 }
-
 }
   size_t alphabet_len = strlen (suffix_alphabet);
-  bool alphabet_slop = (n_units_end % alphabet_len) != 0;
-  while (n_units_end /= alphabet_len)
-suffix_needed++;
-  suffix_needed += alphabet_slop;
+  uintmax_t max_units = 1;
+  while (max_units < n_units_end)
+{
+  suffix_needed++;
+  max_units *= alphabet_len;
+}
   suffix_auto = false;
 }
 
diff --git a/tests/split/suffix-auto-length.sh 
b/tests/split/suffix-auto-length.sh
index e5594d878..691c31ad4 100755
--- a/tests/split/suffix-auto-length.sh
+++ b/tests/split/suffix-auto-length.sh
@@ -50,4 +50,8 @@ rm -f x*
 # as that would result in an incorrect order for the total output file set
 returns_ 1 split --numeric-suffixes=100 --number=r/100 file.in || fail=1
 
+truncate -s0 file.in || framework_failure_
+
+returns_ 0 split --numeric-suffixes --number=r/110 file.in || fail=1
+
 Exit $fail
-- 
2.21.0

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Assaf Gordon]

Hello,

On 2019-04-15 11:55 a.m., C de-Avillez wrote:

19.04:


It is worth noting that Ubuntu 19.04 has not been officially released
yet, so you are testing on a development branch (or a release-candidate,
or a special built infrastructure as hinted by your path).


cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30


[...]


On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson  wrote:


$ file /bin/date
/bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
stripped


I just downloaded a recent daily snapshot of
ubuntu desktop live CD for amd64 from 
http://cdimage.ubuntu.com/daily-live/current/ .

The file "disco-desktop-amd64.iso" dated 2019-04-13 22:28 size 1.9GB,
with the following checksum:

  $ sha1sum disco-desktop-amd64.iso
  b89fb143b51e17482a3882abe2f5f4e3b69942fe  disco-desktop-amd64.iso

Booting with QEMU as live-cd, I tested the same command and got "9" as
the (correct) result. So this can't be easily reproduced.

An interesting benefit of reproducible builds is that I see on the
live-cd image the sha1 checksum of "/bin/date" is the same as you listed
above. This hints to me the problem is somewhere else in your setup.

As this is not an official release, we really can't support it.
You'll have to dig further and see what is the issue.

A good starting point is adding the "--debug" option to date(1)
and examining its output.

regards,
 - assaf

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Bernhard Voelker]

On 4/15/19 9:41 PM, Assaf Gordon wrote:
> A good starting point is adding the "--debug" option to date(1)
> and examining its output.

Hi Assaf,

I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git:

  $ src/date --debug '+%-Y' -d '- 2010 years'
  date: parsed relative part: -2010 year(s)
  date: input timezone: system default
  date: using current time as starting value: '22:10:37'
  date: using current date as starting value: '(Y-M-D) 2019-04-15'
  date: starting date/time: '(Y-M-D) 2019-04-15 22:10:37'
  date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
0009-04-15 22:10:37'
  src/date: invalid date '- 2010 years'

Have a nice day,
Berny

bug#35295: unrecognized file system type 0x794c7630

[Manuel Vera Co]

Hi,

I am trying to monitor an ipsec vpn with the following command:
run monitor vpn ipsec

But it shows the following message

tail: unrecognized file system type 0x794c7630 for ‘/var/log/messages’.
please report this to bug-coreutils@gnu.org. reverting to polling

Thanks a lot.

*Manuel Antonio Vera Salgado*
Solutions Architect.
Itera Colombia S.A.
Pbx: (+57-1) 5190611
Mob: (+57) 3125605335
manuel.v...@iteraprocess.com 
www.iteraprocess.com
www.it-institute.org
[image: http://www.catalogodesoftware.com/files/Itera_IT.jpg]
[image:
http://everest.iteraprocess.org/DISENO/D2/itera_general/apoyo_RH/eco-friendly_small.png]

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Assaf Gordon]

Thanks Bernhard,

On 2019-04-15 2:14 p.m., Bernhard Voelker wrote:

I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git:

   $ src/date --debug '+%-Y' -d '- 2010 years'

[]

   date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
0009-04-15 22:10:37'


This makes it easy to pinpoint (hooray for "--debug" :) ).

This error is given if gnulib's "mktime_z" fails
to convert the adjusted "struct tm" to "time_t"
(adjusted because its tm_year was decremented by 2010).

https://opengrok.housegordon.com/source/xref/gnulib/lib/parse-datetime.y#2177

To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
issue, can you (and/or others) try the attached C program?

It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.

Because the adjustment is to year 9 (about 1961 years before epoch),
the time_t value is negative. perhaps that's the issue? or perhaps
combined with a specific timezone it becomes problematic?

On my system it gives:

  $ gcc -o inv-year inv-year.c

  $ ./inv-year
  time() = 1555361050
  localtime() = 2019-04-15 14:44:10
(mday=15 wday=1, isdst=1)
  struct tm (after adjustment) = 0009-04-15 14:44:10
 (mday=15 wday=1, isdst=1)
  mktime() after date adjustment = -61874070118



regards,
 - assaf






/* A test program to help with https://bugs.gnu.org/35289#28

compile with:
gcc -o inv-year inv-year.c

written by Assaf Gordon (assafgor...@gmail.com).
placed under public domain.
*/
#include 
#include 
#include 
#include 

int main()
{
	time_t now = time(NULL);
	if ( now == ((time_t) -1))
		err(1, "time() failed");
	printf("time() = %ld\n", (signed long)now);

	struct tm *a = localtime(&now);
	if (!a)
		err(1, "localtime(now) failed");

	printf("localtime() = %04d-%02d-%02d %02d:%02d:%02d\n"
   "  (mday=%d wday=%d, isdst=%d)\n",
		a->tm_year+1900,a->tm_mon+1,a->tm_mday,
		a->tm_hour, a->tm_min, a->tm_sec,
		a->tm_mday, a->tm_wday, a->tm_isdst);

	struct tm b;
	memcpy (&b, a, sizeof b);

	/**
	*  Test date adjustment by changing 'b' members
	**/
	b.tm_year -= 2010;

	printf("struct tm (after adjustment) = %04d-%02d-%02d %02d:%02d:%02d\n"
	   "   (mday=%d wday=%d, isdst=%d)\n",
		b.tm_year+1900,b.tm_mon+1,b.tm_mday,
		b.tm_hour, b.tm_min, b.tm_sec,
		b.tm_mday, b.tm_wday, b.tm_isdst);

	time_t notnow = mktime (&b);
	if ( notnow == ((time_t) -1) )
		err(1, "mktime() failed");

	printf("mktime() after date adjustment = %ld\n", (signed long)notnow);

	return 0;
}

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

cerdea@piatam:~/Downloads$ gcc -o inv-year inv-year.c
cerdea@piatam:~/Downloads$ ./inv-year
time() = 1555368087
localtime() = 2019-04-15 17:41:27
 (mday=15 wday=1, isdst=1)
struct tm (after adjustment) = 0009-04-15 17:41:27
  (mday=15 wday=1, isdst=1)
inv-year: mktime() failed: Value too large for defined data type
1 cerdea@piatam:~/Downloads$

On Mon, Apr 15, 2019 at 3:55 PM Assaf Gordon  wrote:
>
> Thanks Bernhard,
>
> On 2019-04-15 2:14 p.m., Bernhard Voelker wrote:
> > I can easily reproduce here on my regular openSUSE:Tumbleweed from latest 
> > git:
> >
> >$ src/date --debug '+%-Y' -d '- 2010 years'
> []
> >date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
> > 0009-04-15 22:10:37'
>
> This makes it easy to pinpoint (hooray for "--debug" :) ).
>
> This error is given if gnulib's "mktime_z" fails
> to convert the adjusted "struct tm" to "time_t"
> (adjusted because its tm_year was decremented by 2010).
>
> https://opengrok.housegordon.com/source/xref/gnulib/lib/parse-datetime.y#2177
>
> To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> issue, can you (and/or others) try the attached C program?
>
> It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
>
> Because the adjustment is to year 9 (about 1961 years before epoch),
> the time_t value is negative. perhaps that's the issue? or perhaps
> combined with a specific timezone it becomes problematic?
>
> On my system it gives:
> 
>$ gcc -o inv-year inv-year.c
>
>$ ./inv-year
>time() = 1555361050
>localtime() = 2019-04-15 14:44:10
>  (mday=15 wday=1, isdst=1)
>struct tm (after adjustment) = 0009-04-15 14:44:10
>   (mday=15 wday=1, isdst=1)
>mktime() after date adjustment = -61874070118
> 
>
>
> regards,
>   - assaf
>
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

On 15/04/2019 21:55, Assaf Gordon wrote:

To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
issue, can you (and/or others) try the attached C program?

It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.

Because the adjustment is to year 9 (about 1961 years before epoch),
the time_t value is negative. perhaps that's the issue? or perhaps
combined with a specific timezone it becomes problematic?


For me it gives:

$ ./inv-year
time() = 1555369320
localtime() = 2019-04-16 00:02:00
  (mday=16 wday=2, isdst=1)
struct tm (after adjustment) = 0009-04-16 00:02:00
   (mday=16 wday=2, isdst=1)
inv-year: mktime() failed: Value too large for defined data type


And debug gives:

$ date +%-Y -d "- 112 years" --debug
date: parsed relative part: -112 year(s)
date: input timezone: system default
date: using current time as starting value: '00:04:32'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:04:32'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: error: adding relative date resulted in an invalid date: '(Y-M-D)
1907-04-16 00:04:32'
date: invalid date ‘- 112 years’

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

It has to be something messing/interacting with coreutils/date on
19.04 (and probably on Tumbleweed).

I created a new container with 19.04, and then:
* apt build-dep coreutils
* apt install rsync wget git
* git clone git://git.sv.gnu.org/coreutils
* cd coreutils
* export FORCE_UNSAFE_CONFIGURE=1 # too lazy to adduser
* ./boostrap
* ./configure
* make

at the end of the build I ran both the provided date and the
just-built one. Both ran correctly:

root@u1904:~/coreutils# date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:39'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:39'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:39'
date: '(Y-M-D) 0009-04-16 00:30:39' = -61874062161 epoch-seconds
date: timezone: system default
date: final: -61874062161.081576777 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC+00)
9

root@u1904:~/coreutils# src/date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:49'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:49'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:49'
date: '(Y-M-D) 0009-04-16 00:30:49' = -61874062151 epoch-seconds
date: timezone: system default
date: final: -61874062151.239637280 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC+00)
9

I then compiled & ran Asaf's inv-year.c:

root@u1904:~# gcc -o inv-year inv-year.c
root@u1904:~# ./inv-year
time() = 1555375408
localtime() = 2019-04-16 00:43:28
  (mday=16 wday=2, isdst=0)
struct tm (after adjustment) = 0009-04-16 00:43:28
   (mday=16 wday=2, isdst=0)
mktime() after date adjustment = -61874061392

So: a pristine 19.04 runs it. My laptop (which is my work machine,
full of other packages & programs), does not.

Oh -- Assaf, yes, I am very well aware 19.04 has not yet been
released. But -- unless we find something critical -- it is basically
what will be  released in a few days. I do not expect a rebuild of the
coreutils package, for example.

Cheers,

..C..

On Mon, Apr 15, 2019 at 6:11 PM O. Emmerson  wrote:
>
> On 15/04/2019 21:55, Assaf Gordon wrote:
> > To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> > issue, can you (and/or others) try the attached C program?
> >
> > It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
> >
> > Because the adjustment is to year 9 (about 1961 years before epoch),
> > the time_t value is negative. perhaps that's the issue? or perhaps
> > combined with a specific timezone it becomes problematic?
>
> For me it gives:
>
> $ ./inv-year
> time() = 1555369320
> localtime() = 2019-04-16 00:02:00
>(mday=16 wday=2, isdst=1)
> struct tm (after adjustment) = 0009-04-16 00:02:00
> (mday=16 wday=2, isdst=1)
> inv-year: mktime() failed: Value too large for defined data type
>
>
> And debug gives:
>
> $ date +%-Y -d "- 112 years" --debug
> date: parsed relative part: -112 year(s)
> date: input timezone: system default
> date: using current time as starting value: '00:04:32'
> date: using current date as starting value: '(Y-M-D) 2019-04-16'
> date: starting date/time: '(Y-M-D) 2019-04-16 00:04:32'
> date: warning: when adding relative months/years, it is recommended to
> specify the 15th of the months
> date: error: adding relative date resulted in an invalid date: '(Y-M-D)
> 1907-04-16 00:04:32'
> date: invalid date ‘- 112 years’
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Paul Eggert]

C de-Avillez wrote:

So: a pristine 19.04 runs it. My laptop (which is my work machine,
full of other packages & programs), does not.


You might try running 'strace' on pristine 19.04 and on your laptop, and see if 
you can spot the difference in system calls. Possibly you have some stuff on 
your laptop that is leftover from an earlier release.

bug#35295: unrecognized file system type 0x794c7630

[Bernhard Voelker]

Hello,

On 4/15/19 10:44 PM, Manuel Vera Co wrote:
> I am trying to monitor an ipsec vpn with the following command:
> run monitor vpn ipsec
> 
> But it shows the following message
> 
> tail: unrecognized file system type 0x794c7630 for ‘/var/log/messages’.
> please report this to bug-coreutils@gnu.org. reverting to polling
> 
> Thanks a lot.

Thank you for the report.

This has been fixed in coreutils version 8.25 - meaning you
are likely using an older version.

For more details, see here:
  https://www.gnu.org/software/coreutils/filesystems.html

Have a nice day,
Berny