Hi,
you might be running into this issue:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1925204&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=ts7ZLN5_srcF3E4faT54Sy7e6mS9J6_NLmE5JzpQZNY&s=QJu
I get "nan" on one SL7.9 computer but a "0" on another. Not sure what causes
the difference.
I get the same 'nan' on three SL 7.9 computers, but it works ok on a
CentOS 7.9 machine. Here is an excerpt from 'rpm -qi coreutils' on
CentOS 7.9:
Source RPM : coreutils-8.22-24.el7_9.2.src.rpm
Build Date : Mon 16 Nov 2020 02:24:59 PM PST
Build Host : x86-01.bsys.centos.org
and here is
Greetings,
Thanks for checking. That seems to fit that every other distro is fine.
But I've now check a dozen different systems on SL 7.9 and all show it.
Thanks!
~Stack~
On 2/10/21 7:37 PM, Konstantin Olchanski wrote:
here goes, all on physical machines.
sl6, macos: no numfmt, sorry
u
here goes, all on physical machines.
sl6, macos: no numfmt, sorry
ubuntu lts 20.04, centos-7, rhel-8 (ahem!):
$ echo 0 | numfmt
0
perhaps your 80387 chip is faulty. (happened to us once
on an R3000/R3010 SGI workstation)
K.O.
On Wed, Feb 10, 2021 at 06:17:26PM -0600, ~Stack~ wrote:
> Greeti
Greetings,
Curious if anyone else can replicate this. I initially saw this in a
certain upstream vendor 7.9, but I'm having issues replicating it and
it's only in a certain environment (virtual and I've done strange and
awful things to that as I've been trying to understand an unrelated
proje
There's AlmaLinux aka CloudLinux in the news recently. They are already a fork
of RHEL and not a green fields stsartup like Rocky and are looking to woo
jilted Centos users.
From: owner-scientific-linux-us...@listserv.fnal.gov
on behalf of Keith Lofstrom
Sent: