Lolix, I’d ask you not to package pinxi, this is a purely development branch, that can and does get up to 10 release per day. pinxi -U is the best updating method, because that guarantees you are running the actual current pinxi release.
That set of uninitialized errors is exactly the type of thing I’m looking for, that means an assumption that a certain data type could never be null was wrong, astounding just how many of those I’ve gotten in the past week, which is why the more diverse the systems testing it, the better. Those are usually easy to fix.
This is a case where I’d want to see the --debug data set, because I need to fiind the root cause for that, it should never be null, technically, internally, so I would want to see how that came about so I can actually fix the issue, not patch over it. This comes from lsusb -v
USB is a new feature, so it’s most likely to have bugs, since usb data is just as dirty, inconsistent, and unreliable as any other vendor generated data is. But that particular error is an internal logic bug I’m pretty sure, there must have been some type of variation in the structure of lsusb -v that confused pinxi.
I often release a new version, say, 0383-p 10 minutes after 0382-p, so a specific person can test the fixes and ensure they are correct.
johnvan54, that looks like some bugs for sure, however, you truncated your sensors output so I can’t actually resolve the issue. All data samples need to be complete, as is, or just run --debug 21 or --debug 22 and I get the data exactly as the system gives it, which then lets me inject that data into pinxi directly to figure out the issue.
Running pinxi I get 12686% HDD used, while in inxi and pinxi -F it says 12.4% used
looks like a math problem there, except those two things should be doing the same math.
I have some tentative gpart stuff in pinxi, but it’s mostly for BSDs, however, one primary purpose of rewriting inxi into perl was to make the creation of new features much much easier (it is), and the debugging of existing features far easier (it is).
eugen-b, to uninstall, it’s a simply script: rm -f /usr/local/bin/pinxi and then:
which will show you where your pinxi . directory is, probably $HOME/.local/share/pinxi in most cases on modern systems, unless XDG data/config directories are used, then they will be in those.
Feedback looks good so far, and confirms that pinxi is not yet ready for stable 3.00 release, but we’re getting there! Thanks for testing it.