===================================================================================== Version: 3.1.09 Patch: 00 Date: 2020-11-11 ----------------------------------- Changes: ----------------------------------- Bug fixes, new features!! Update now!! Or don't, it's up to you. Bugs: 1. Let's call some of the android fixes and debugger failures bugs, why not? Those are fixed. Note that many of these fixes will impact any system that is ARM based, not just android. Fixes: 1. Related to issue #226 which was a fine issue, fine tuned the debugger debuggers to allow for smoother handling of /sys parse failures. Also added debugger filters for common items that would make the /sys parser hang, oddly, most seem to be in /sys/power for android devices. 2. Added some fine-tunings for possible mmcblk storage paths, in some cases, an extra /block is added, which made inxi think mounted drives were unmounted. I've never seen this extra /block except on mmcblk devices on android, but you never know, it could be more widespread. 3. Also mainly related to android, but maybe other ARM devices, in some cases, an errant 'timer' device was appearing as a cpu variant, which is wrong. That was a corner case for sure, and part of the variant logic in fact uses timer values to assign the actual cpu variants, but it was wrong in this case because it was ....-timer-mem, not ...-timer, which led to non-existent CPU variants showing. 4. Issue #236 by ChrisCheney pointed out that inxi had never updated its default /proc/meminfo value to use the newer MemAvailable as default if present, which led to incorrect memory used values showing up. That's because back in the old days, we had to construct a synthetic Memory used from MemFree, buffers, cache, etc, but that wasn't always right, since sometimes the cache actually isn't available, often is, but not always. https://github.com/torvalds/linux/commit/34e431b0ae398fc54ea69ff85ec700722c9da773 This commit on the kernel explains it pretty clearly. Thanks Chris for bringing this to our attention. 5. Kind of more future-proofing, got rid of a bunch of hard-coded strings internally and switched those to use the row_defaults values, which is where string messages are supposed to go. That was mostly in the initial program check messages on start-up, but also a few other stray ones. Also consolidated them a bit to get rid of redundant messages, and added more variable based messages, like for missing/permissions on programs etc. The idea in general is that all the strings are contained in subs so that in theory they could be swapped for other strings, eg, languages, but honestly, I no longer see this as very likely to ever happen. But it's still nice to be consistent internally and not get sloppy with english strings. This also got rid of some largely redundant items in row_defaults, and expanded the list of handled events, and of variable based events, so it shouldn't be as necessary to add new row_defaults items for similar events. Enhancements: 1. Debugger item to maybe try to find distro OEM, this was connected with issue #231 but the issue poster vanished, and didn't do the work required, so this one won't happen until someone who cares [not me, that is] does the required work. It's always funny to see how quickly people vanish when they have to do the actual boring research that they want me to do for them, lol. Or maybe, sigh is more appropriate than lol. But it is pretty much par for the course, sad to say. Or maybe this was an OEM hoping to have someone do their corporate work for them for free, who knows. Anyway, there's a certain category of items that I'm reasonably happy to implement, but NOT if I have to do all the boring research work, so such features being added will depend on the poster actually doing the boring work. I've gotten burned on this a few times, cpu arch: for example, some guy said he'd track that and provide updates, he never even made it to the first release, so I got stuck doing that one forever after. But that one at least has some general value, so that's ok more or less, but I definitely won't take on stuff that I really don't personally care at all about unless the person requesting the feature does all the work beforehand. The boring part, that is.... 2. Related to issue #226, much improved android ID and many small android fixes for machine data etc. Now uses /system/build.prop for some data, which is a nice source, sadly, most modern android devices seem to be locked down, with both build.prop and /sys locked down, which makes inxi unable to actually get any of that data, but if your device either does not have these root only readable, or if you have an android rooted phone, the android support will be more informative. Hint: if you run inxi in termux on your non rooted android device, and it shows you what android version you are using in System:... Distro: line, then your android is not locked down. I have one such phone, android 7.1, but I cannot say how usual or non usual this is. The poster of issue #226 for instance had to root his android 7 phone to get this data to display. So it seems to vary quite a bit. Note that due to these file system lockdowns, in general, trying to do android arm support remains largely a waste of time, but on some devices sometimes, you can now get quite nice system info. As I noted in the issue, if I can't get the features to work on a non rooted phone in my possession, I'm probably not going to try to do the work because it's too hard to try to work on android issues without having the device in front of you for testing and debugging. In this case, one of my phones did work, so I did the work just to see where android is at now. Android showed some slightly odd syntaxes for some devices, but those are now handled where I got a dataset for them that revealed the changes required. 3. Also related to issue #226 for termux in android, will show -r info. That's an apt based package manager, but termux puts the apt files somewhere else so needed to change paths if those alternate paths existed for apt. 4. Added PARTFLAGS to debugger to see what knd of data that will yield, that's a lsblk key/value pair. 5. Just because it's easy to do, added new -Ixxx item, wakeups: which is a subset of Uptime, this will show how many times the system has been woken from suspend since the last boot. If the system has never been suspended, shows 0. 6. Many more disk vendors and disk IDs. The list just never ends, possibly a metaphor for something, the endless spinning of maya, who knows? 7. Added newest known ubuntu release, hirsute, to buntu ID logic. Might as well catch them early, that will be 21.04. ----------------------------------- -- Harald Hope - Wed, 11 Nov 2020 14:57:38 -0800 ===================================================================================== Version: 3.1.08 Patch: 00 Date: 2020-10-16 ----------------------------------- Changes: ----------------------------------- Bug fixes, updates!!! Yes!! Why wait!!! Can't stay frozen forever! Bugs: 1. Not an inxi bug, but a weird change in defaults for ubuntu GNOME ENV variable values when running at least the gnome desktop, result to end users appears to be a bug. This resolves issue #228 Note that so much weird non desktop data was put into those environmental variables that inxi simply could make no sense of it. The fix was to make the detections more robust, using regex instead of string compare, as well as to at least try to strip out such corrupted data values, though that can never be fully predictable. As far as I know, this issue only hits ubuntu gnome desktops, I've never seen these value corruptions on any other distro, or on any other ubuntu desktop, though they may be there, but I'm not going to test all the ubuntu spins to find out. I'm hoping the combination of logic fixes and junk data cleaning will handle most future instances of these types of corruptions automatically. Again, this only happens on relatively laste ubuntu gnomes as far as I know. Fixes: 1. An oversight, added sshd to list of whitelisted start clients. This permits expected output for: ssh inxi -bay that is, running inxi as an ssh command string. Should have done that a while ago, but better late than never. This corrects issue #227, or at least, has a better default, it worked fine before, but required using --tty to reset to default terminal behavior. The problem is that if inxi can't determine what it's running in, it defaults to thinking it's in an IRC client, and switches to IRC color codes, among other changes. But it was nice to get sshd covered automatically so users don't have to know the --tty option. Changes: 1. More disk vendors and vendor IDs!!! Yes, that's right, the list never ends!! ----------------------------------- -- Harald Hope - Fri, 16 Oct 2020 13:43:40 -0700 ===================================================================================== 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 ----------------------------------- Changes: ----------------------------------- New features, new changes, new bug fixes!!! Excitement!!! Thrills!!! Bugs: 1. Forgot to set get Shell logic in inxi short form, oops, so Shell remained blank, only inxi short, which I rarely use so I didn't notice. 2. Failed to test pacman-g2 for packages, had wrong query argument, so it failed. Also failed to test for null data, so showed errors for packages as well. Both fixed. 3. A big bug, subtle, and also at the same time, an enhancement, it turns out NVME drives do NOT follow the age old /proc/partitions logic where if the minor number is divisible by 16 or has remainder 8 when divided by 16, it's a primary drive, not a partition. nvme drives use a random numbering when > 1 nvme drives are present, and the old tests would fail for all nvme drivers more than the first one, which led to wrong disk size totals. Thanks gardotd426 who took the time to help figure this out in issue #223 - fix is to not do that test for nvme drives, or rather, to add a last fail test for nvme primary nvme[0-9]n[0-9] drive detections, not the minor number. Fixes: 1. Corrected indentation for block sizes, children were not indented. 2. Updated some older inxi-perl/docs pages, why not, once in a while? 3. Kernel 5.8 introduces a changed syntax to gcc string location, this has been corrected, and the kernel gcc version now shows correctly for the previous syntax and the new one. Hopefully they do not change it again, sigh... 4. Removed string 'hwmon' sensors from gpu, those are not gpu sensors, and are also usually not board/cpu sensors, but things like ath10, iwl, etc, network, or disk sensors, etc. In some cases hwmon sensor data would appear Enhancements: 1. Big sensors refactor, now inxi supports two new sensors options: --sensors-exclude - which allows you to exclude any primary sensor type[s]. Note that in the refactored logic, and in the old logic, gpu sensors were already excluded. Now other hardware specific sensors like network are excluded as well. --sensors-use - use ONLY list of supplied sensor IDs, which have to match the syntax you see in lm-sensors sensors output. Both accept comma separated list of sensors, 1 or more, no spaces. The refactor however is more far reaching, now inxi stores and structures data not as a long line of sensors and data without differentiation, but by sensor array/chip ID, which is how the exclude and use features can work, and how granular default hardware sensor exclusions and uses can happen. This is now working in the gpu sensors, and will in the future be extended to the newer 5.7/5.8 kernel disk temperature sensors values, which will lead in some cases to being able to get sensors data for disks without root or hddtemp. This is a complicated bit of logic, and I don't have time to do it right now, but the data is now there and stored and possible to use in the future. To see sensors structures, use: inxi -s --dbg 18 and that will show the sensors data and its structures, which makes debugger a lot easier for new features. This issue was originally generated by what was in my view an invalid complaint about some inxi sensors defaults, which led me to look more closely at sensors logic, which is severely lacking. More work on sensors will happen in the future, time, health, and energy permitting. 2. Added Watts, mem temp, for amdgpu sensors, as -sxxx option. More gpu sensor data will be added as new data samples show what will be available for the free modules like amdgpu, nouvean, and the intel graphics modules. 3. More disk vendors and IDs, as noted, the list never ends, and it hasn't ended, so statement remains true. Thanks linux-lite hardware database. Changes: 1. This has always bugged me since it was introduced, the primary cpu line starter Topology: which was only technically accurate for its direct value, not its children, and also, in -b, cpu short form was using the value as the key, which is a no-no, I'd been meaning to fix that too, but finally realized if I just make the primary CPU line key be 'Info:', which is short, yet non-ambiguous, it would solve both problems. To keep the -b cpu line as short as before, I removed the 'type:' and integraged that value into the primary Info: string: CPU: Info: 6-Core AMD Ryzen 5 2600 [MT MCP] speed: 2750 MHz min/max: 1550/3400 MHz -b 3.1.05 and earlier: CPU: 6-Core: AMD Ryzen 5 2600 type: MT MCP speed: 1515 MHz min/max: 1550/3400 MHz These resolve something that has irked me for quite a while, 'Topology:' didn't fit, it was too geeky, and worst, it only applied to the value directly following it, NOT to the rest of the CPU information. It also could not be shortened or abbreviated since then it would have made no actual sense, like topo:, and the same issue with value being used for key in -b, and wrong word for line starter in -C would have existed. Besides, someone might think I was trying to make a subtle reference to the great Jodorowsky film 'El Topo', which would be silly, because that's art, and this is just some system specs that are reasonably readable... 2. Was using opendns for WAN dig IP address, but apparently cysco bought that company, and now I've noticed the old opendns dig queries were failing more and more, so replaced that with akamai dig requests. Also made the WAN IP fallback to HTTP IP method if dig failed. New option: --no-http-wan and config item NO_HTTP_WAN with override --http-wan added to let you switch off http wan IP requests if you want. Note that if dig fails, you will get no wan ip address. Updated/improved error messages to handle this more complex set of wan ip options, so hopefully the error alert message will in most cases be right. 3. To future proof inxi, switched debugger upload location to ftp.smxi.org/incoming from the old techpatterns.com/incoming. Updated man/help to remove those urls too. ----------------------------------- -- Harald Hope - Sun, 16 Aug 2020 14:28:58 -0700 ===================================================================================== Version: 3.1.05 Patch: 00 Date: 2020-07-26 ----------------------------------- Changes: ----------------------------------- Bug fixes!!! New Features!! Why wait!!! Bugs: 1. Issue #220 on github: inxi misidentified XFCE as Gnome. This was a kind of core issue, and pointed to some logic that needed updating, and some inadequate assumptions made, and some too loose cascade of tests. Hopefully now xfce will almost never get misidentified, and the other primary desktops ID'ed either from $ENV or from xrop -root will be slightly more accurately identified as well. Note that this fix creates a possibility for obscure misconfigured desktops to be ID'ed wrong, but in this case, that will be technically a bug for them, but with the new fixes, that situation will be cleaner to handle internally in the desktop ID logic. Also tightened the final Gnome fallback detection to not trigger a possible false positive, it was testing for ^_GNOME but that is not adequate, because some gnome programs will trigger these values in xprop -root even if GNOME is not running. Should be safer now, hopefully no new bugs will be triggered by these changes. Fixes: 1. Missed an indentation level for -y1, gcc alt should have been indented in one more level, now it is. 2. In disk vendors/family, didn't clean items starting with '/', this is now corrected. Yes, some do, don't ask me why. Might be cases like: Crucial/Micron maybe, where the first ID is grabbed, not sure. Enhancements: 1. New Disk vendors, vendor IDs!!! The list never ends!!! We've finally found infinity, and it is the unceasing wave of tiny and not so tiny disks and their Ids. 2. New feature: for -Aa, -Na/-na/-ia, -Ga, now will add the modules the kernel could support if they were available on the Device-x lines of those items. This was made an -a option because it really makes no sense, if it's a regular option, users might think that for example an nvidia card had a nouveua driver when it didn't, when in fact, all the kernel is saying is that it knows those listed modules 'couid' be used or present. This corresponds to the Display: item in -Ga, that lists 'alternate:' drivers that Xorg knows about that could likewise be used, if they were on the system. In other words these are --admin options because otherwise users might get confused, so this is one where you want to know the man explanation before you ask for it. It is useful however if you're not sure what your choices are for kernel modules. When the alternate driver is the same as the active driver, or if none is found, it does not show the alternate: item to avoid spamming. ----------------------------------- -- Harald Hope - Sun, 26 Jul 2020 19:10:21 -0700 ===================================================================================== Version: 3.1.04 Patch: 00 Date: 2020-06-28 ----------------------------------- Changes: ----------------------------------- New version, new man, huge update, bug fixes, cleanups, updates!! What started as a relatively minor issue report ended up with a refactor of big chunks of some of the oldest code and logic in inxi. So many bugs and fixes, updates, and enhancements, that I will probably miss some when I try to list them. Bugs: 1. In the process of fixing an issue about sudo use triggering server admin emails on failure, when --sudo/--no-sudo and their respective configuration items were added, sudo was inadvertently disabled because the test ran before the options were processed, which meant the condition to set sudo data was always false, so sudo for internal use was never set. The solution was to set a flag in the option handler and set sudo after options or configs run. 2. Issue #219 reported gentoo and one other repo type would fail to show enabled repos, and would show an error as well, this was due to forgetting to make the match test case insensitive. If only all bugs were this easy to fix!! 3. I'd seen this bug before, and couldn't figure out why it existed. It turned out that the partition blacklist filters were running fine in the main partition data tool, but I had forgotten to add in corresponding lsblk partition data filters, lol, so when the logic went back and double checked for missing partitions. This feature had been, if i remember right, to be able to show hidden partitions, which the standard method didn't see, but lsblk did, anyway, when the double check and add missing partitions logic ran, inxi was putting back in the blacklisted partitions every time, despite the original blacklists working well and as intended. This was fixed by adding in all the required fs type blacklists, then adding in comments above each black list reminding coders that if they add or remove from one blacklist, they have to do the same on the other. 4. Found while testing something unrelated on older vm, the fallback case for cpu bugs, which was supposed to show the basic /proc/cpuinfo cpu bugs, was failing inexplicably because the data was simply being put into the wrong variable name, sigh. Fixes: 1. While not technically an inxi bug, it would certainly appear that way to anyone who triggered it. We'd gotten issue reports before on this, but they were never complete, so couldn't figure it out. Basically, if someone puts inxi into a simple script that is in $PATH [this was the missing fact needed to actually trigger this bug in order to fix it], the script [not inxi], will then enter into an endless loop as inxi queries it for its version number using