diff options
| author | 2020-09-30 20:52:00 -0400 | |
|---|---|---|
| committer | 2020-09-30 20:52:00 -0400 | |
| commit | 88dcfb275e8e67387fb38a1b8ff1b213e616cba8 (patch) | |
| tree | b133757102674effe652104fed68815af9749dfd /inxi.changelog | |
| parent | e06112ed81893de328da38fbd41a435359cb7cd3 (diff) | |
New upstream version 3.1.07-1.upstream/3.1.07-1
Diffstat (limited to 'inxi.changelog')
| -rw-r--r-- | inxi.changelog | 58 |
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 +----------------------------------- +Changes: +----------------------------------- + +Bug fixes, feature updates, changes!! + +Bugs: +1. There was a glitch in the pattern that made -D samsung / seagate not ID right, +fixed. + +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. + +Fixes: +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. + +Changes: +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 |
