path: root/inxi.changelog
diff options
Diffstat (limited to 'inxi.changelog')
1 files changed, 65 insertions, 6 deletions
diff --git a/inxi.changelog b/inxi.changelog
index b76d11e..e6efbde 100644
--- a/inxi.changelog
+++ b/inxi.changelog
@@ -1,11 +1,73 @@
+Version: 3.0.37
+Patch: 00
+Date: 2019-11-19
+New version, man page, exciting changes!!
+1. issue #200 - forgot to add all variants for -p, now works with --partition-full
+and --partitions-full
+2. issue #199 - another one, forgot to add --disk to -D for long version. Thanks
+adrian15 for both of these, he was testing something and discovered these were
+3. Issue #187 an issue with RAID syntax not being handled in a certain case,
+thanks EnochTheWise for following through on this one. This turned out to be
+a bad copy paste, a test pattern did not match the match pattern.
+1. Fixed some docs typos.
+2. Issue #188 fixed protections and filters for some glxinfo output handlers.
+3. Issue #195, for Elbrus bit detection.
+4. Added filter to cpu data, was not skipping if arm, so Model string
+was treated numerically.
+1. Added rescatux to Debian system base detections. This closes issue #202, again
+from adrian15, thanks.
+2. For cpu architecture, updated for latest AMD ryzen and other families, like
+Zen 3, which is just coming out re available data. Also latest Intel, which are
+trickier to ID right now, but I think I got the latest ones right,
+That's things like coffee lake, amber lake, comet lake, etc.
+3. Huge one, full (hopefully out of the box) Russian Elbrus CPU support. Thanks
+to the alt-linux and the others who helped provide data and feedback to get support.
+Note that this was also part of correcting 64 bit detection for e2k type, which
+is how Elbrus IDs internally. See issue #197 which I've left open for the time
+being for more information on this CPU and how it's now handled by inxi.
+Note all available data should now work for Elbrus, including physical cpu/core
+counts etc. Elbrus do not show flag information, nor do they use min/max speed,
+so that data isn't available, but everything else seems to work well.
+4. Eternal disk vendors. Thanks linux lite hardware database, you continue to
+help make the disk vendor feature work by supplying every known vendor ever seen.
+5. To close debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942194
+Note that the fix is simply to give the user the option to disable this behavior
+with the new --no-sudo and NO_SUDO configuration file options. This issue should
+never have been filed as a bug since even the poster admitted it was a wishlist
+item, but because of how debian bug tracker works, it's hard to get rid of
+invalid bugs. Note that this is the internal use of sudo for hddtemp and file,
+not starting inxi with sudo, so using this option or configuration item just
+removes sudo from the command. Note that because the user did not do as
+requested, and never actually filed a github wishlist issue, and since his
+request was vague and basically pointless, the fix is just to let you switch
+off sudo, that's all.
+Note that another user had commented on sudo firing off admin emails on servers,
+and that was in a different context, some time ago, that's what this option really
+is useful for, if you want to just disable sudo fires internally to avoid admin
+server email alerts, basically.
+-- Harald Hope - Tue, 19 Nov 2019 20:18:15 -0800
Version: 3.0.36
Patch: 00
Date: 2019-08-14
-New version, many small fixes. And a hall of shame, LOL.
+New version, many small fixes.
1. Issue #188 exposed a situation in glxinfo where the required opengl fields are
@@ -68,15 +130,12 @@ may exist.
1. Issue #187 EnochTheWise (?) did not supply the required debugger data so there
is a RAID ZFS issue that will not get fixed until the required debugger data is
-supplied. Please do not waste all our time filing an issue if you have no
-intention of actually following through so we can get it fixed.
Note that a key way we get issues here is from Perl errors on the screen, which are
a frequent cause of someone realizing something is wrong. This is why I'm not going
to do a hack fix for the RAID ZFS issue, then the error messages will go away, and
-it will likely never get handled. For examples of good, useful, productive issue
-reports, and how to do them right: #188 and #185, both of which led to good
-improvements in how inxi handles corner cases in those areas.
+it will likely never get handled.
-- Harald Hope - Wed, 14 Aug 2019 10:47:47 -0700