path: root/inxi.changelog
diff options
authorLibravatarUnit 193 <unit193@unit193.net>2020-09-30 20:52:00 -0400
committerLibravatarUnit 193 <unit193@unit193.net>2020-09-30 20:52:00 -0400
commit88dcfb275e8e67387fb38a1b8ff1b213e616cba8 (patch)
treeb133757102674effe652104fed68815af9749dfd /inxi.changelog
parente06112ed81893de328da38fbd41a435359cb7cd3 (diff)
New upstream version 3.1.07-1.upstream/3.1.07-1
Diffstat (limited to 'inxi.changelog')
1 files changed, 58 insertions, 0 deletions
diff --git a/inxi.changelog b/inxi.changelog
index 33fd5d8..f9a382c 100644
--- a/inxi.changelog
+++ b/inxi.changelog
@@ -1,4 +1,62 @@
+Version: 3.1.07
+Patch: 00
+Date: 2020-09-29
+Bug fixes, feature updates, changes!!
+1. There was a glitch in the pattern that made -D samsung / seagate not ID right,
+2. I do not like calling this a bug, because it's not an inxi bug, it's an upstream
+regression in the syntax used in /proc/version, they changed a fully predictable
+gcc version .... to a random series of embedded/nested parentheses and other random
+junk. inxi tries to deal with this regression, which will be perceived as a bug in
+systems running kernel 5.8 or newer and inxi 3.1.06 or older, since it will fail to
+show the kernel build compiler version since it can't find it in the string.
+I really dislike these types of regressions caused by bad ideas done badly and
+without any thought to the transmitted knowledge base, but that's how it goes,
+no discipline, I miss the graybeards, who cared about things like this.
+1. more -D nvme id changes, intel in this case.
+2. FreeBSD lsusb changed syntax, which triggered a series of errors when run.
+[hint bsd users, do NOT file issues that you want fixed and then not provide
+all the data required in a prompt and timely manner, otherwise, really,
+why did you file the issue?].
+Note: the fix basically just rejects any row from lsusb that does not have the
+expected syntax/value in the expected place, which was I think the right
+solution given that the change was random, broke expected syntax for lsusb, and
+wasn't really integrateable into existing inxi usb logic, so why fight it?
+Given that at least 99.99% of all lsusb output in the world, including by the
+way OpenBSD's [not sure about most recent version], shows the expected values in
+the expected place, I could see no value in creating a convoluted work-around
+for a non core bsd tool in the first place, so that's what I didn't do.
+See the README.txt for what to do to get issues really handed in BSDs.
+1. -C 'boost' option changed from -xxx feature to -x feature.
+Consider it a promotion!
+2. Added --dbg 19 switch to enable smart data debugging for -Da.
+3. Some new tools to handle impossible data values for some -D situations for SMART
+where the smart report contains gibberish values, that was issue #225 -- tools were
+convert_hex and is_Hex. The utility for these is limited, but might be of use in
+some cases, like handling the above gibberish data value.
+-- Harald Hope - Tue, 29 Sep 2020 16:08:05 -0700
Version: 3.1.06
Patch: 00
Date: 2020-08-16