greerd, I assume this issue re usb audio not showing isn't present any longer. If it is, I'll need data from the latest pinxi --debug 22 to see what's going on.
Cosmos, you have found one of the biggest oversights Poettering made when creating the new /etc/os-release 'standard', which was supposed to replace the last 'standard' of lsb-release. That failure, which is fairly unsurprising for a redhat employee, was to not have a built in category for derived and system base distro data in os-release, thus forcing endless hacks and workarounds which continue to this day.
Basically because there is zero standard way of getting the system base, all one can do is create manual distro by distro work arounds, because each and every one of them is different, antergos and manjaro and Arco, all derived from Arch, each use a different way to determine what their distro name is vs the base distro.
this is kind sad, because literally all that was required when creating the os-release standard, sic, was to actually think about it, and ask, and see what the non corporate outside world from redhat actually needed to be able to have one standard actually serve all distros, not just redhat and redhat funded stuff like fedora. So yes, usually the information there, and no, there's never an easy way to get it. Basically I'd create a small database of known matches then use that to create the system base data, if such a thing were to happen.
Still the same issue regarding usb audio, ran
pinxi --debug 22as normal user and again with sudo. The files sent are
pinxi-mint19-dt-2018-06-14_213733-3.0.12.tar.gzand with sudo
Here's probably roughly what is happening: your lsusb is part of the older Mint base install. inxi is relying on lsusb for usb data. However, your /sys parser showed "AudioQuest DragonFly Red v1.0" as clear as could be asked.
This is because you are running a newer kernel, 4.15, which does know about the roughly 2016 released audioquest red device. The old lsusb however does not know about that device, so while it had the listing for it, it had the product id and vendor id, it did not have the name anywhere, or the product name, or the vendor name. Your original question about why one command showed the data, and the other not, is because there was a sort of bug in the version that did, and it was using /proc/asound/cards as a fallback, it wsn't supposed to do that, but it did, it no longer does I believe, or it does it consistently. So that 'bug' resulted by accident in showing the missing card data, which is also in /proc/asound/cards, which is a really low level weak backup fallback audio source I use internally if everything else failed.
This case is interesting to me because I"ve been increasingly wondering if I can dump lsusb and replace it with a /sys usb parser, though I'd need to keep the lsusb handler for older systems that don't have much data in /sys, and your example is clear indication of a specific situation that would be an enhancement to inxi. I'd resisted because I am not sure I can get all the actual data that lsusb gives me from /sys, but I'll keep looking at that question and checking various datasets to see what would be missing. So far the usb version does not appear to always be present per device or hub, for example, and that's significant information in terms of speed and knowing which port supports which speed.
So there's no bug, and if you were using a newer lsusb, you'd almost certainly see the device listed as expected, but I'm actually surprised that lsusb isn't using something similar to /sys for its data source, only I assume in C, but I can also tell you, lsusb is one of the slowest helper tools inxi uses, really really slow. Really inexcusably slow because I have no doubt I can make it run 5x faster at least if I coded it directly in perl.
I'll have to give some thought to writing a sys usb parser I think.
I am lucky enough to have examples of 3 os-release files from the last 3 mint versions, so I was able to construct rules which should show the system base going back at least mint 17, maybe earlier versions if they used the same os-release syntax as 17.Cosmo. wrote: ⤴Mon Apr 23, 2018 6:03 amIn case h2-1 is still listening:
I just came (while giving support) to the observation, that some users do not know how to find out, on which bunt base a Mint version is built. Although there are other ways to find that out it would be fine, if inxi could show this also, preferably with the -S option (or -Sxx). Something like: Base: Ubuntu xxxxx.
I've added this feature to a few known distros, but it's very specific to each distro, so I have to be sure of several things before I can add a distro to the system base list.
Try latest pinxi, 3.0.12-23 and it should show (note system base is an -xxx option):
Code: Select all
pinxi -Sxxx System:...... Distro: Linux Mint 19 Tara base: Ubuntu Bionic
Code: Select all
NAME="Linux Mint" VERSION="19 (Tara)" ID=linuxmint ID_LIKE=ubuntu PRETTY_NAME="Linux Mint 19" VERSION_ID="19" HOME_URL="https://www.linuxmint.com/" SUPPORT_URL="https://forums.ubuntu.com/" BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/" PRIVACY_POLICY_URL="https://www.linuxmint.com/" VERSION_CODENAME=tara UBUNTU_CODENAME=bionic
Code: Select all
NAME="Linux Mint" VERSION="18.3 (Sylvia)" ID=linuxmint ID_LIKE=ubuntu PRETTY_NAME="Linux Mint 18.3" VERSION_ID="18.3" HOME_URL="http://www.linuxmint.com/" SUPPORT_URL="http://forums.linuxmint.com/" BUG_REPORT_URL="http://bugs.launchpad.net/linuxmint/" VERSION_CODENAME=sylvia UBUNTU_CODENAME=xenial
Code: Select all
NAME="Ubuntu" VERSION="14.04.5 LTS, Trusty Tahr" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 14.04.5 LTS" VERSION_ID="14.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
This might of been answered in the thread, but just in case:h2-1 wrote: ⤴Fri Jun 15, 2018 8:45 pm..
note that no data files contain the actual ubuntu release version, just the name, that's a Mint problem, I can't fix that since I won't make dynamic distro version to name to number matching in distro data, it's too much to maintain over time with endless distros out there.
LM 17.3 - /etc/os-release
https://www.freedesktop.org/software/sy ... lease.html
When I've seen inxi recommended, the options are -Fxz. I finally read the help on the "z" option. The "-z" option "Adds security filters for IP/MAC addresses, serial numbers, location (-w), user home directory name. Default on for IRC clients." I noticed that under the Debugging Options, data can be uploaded automatically to ftp.techpatterns.com. Nothing new, I know. It was in inxi too.
It would be nice, if pinxi had a Confirmation Message before uploading any data.
Nice job on the perl.
I believe the help and man pages make it clear that the data is going to be uploaded with --debug 21 and 22 and obviously, anyone asking for it can also point that out, I try to make that clear for new users who don't know the process.
I'm kind of like a system doctor in terms of this data, I really don't care about the specifics of the data in there beyond what I need to confirm or create a diagnosis or cure, or to build up data for a new feature or a bug fix or whatever. Most sys admin types by the way are like this around data like this, it's just data.
In terms of real privacy, the real crimes are in how big websites like google, facebook, amazon, etc, build up user profiles that are apparently disturbingly accurate, cell phone users hand this type of data to the web without a second thought. Within that scenario, it would be hard to find a person less interested in the technically specific data than me, lol, all I care about is how it's parsed and used, and if the result is correct.
On a technical level, when I was working on a new part of the debugger, a /proc parser, I discovered a weird thing that would expose all of a user's files in the debugger data, and because in my view that was unacceptable, I completely blocked that entire part of the data gatherer because I don't want to ever see that data, nor did I want it ever to be in the debugger.
Not quite sure whether appending my messge to this thread, which you started in order to recruit beta testers, will be the best way.
Yet, I would like to draw your kind attention to my report here: inxi 3.0.14 tells "nouveau" unloaded, inxi 2.3.56 says "loaded".
Linux Mint 18.1 64-bit Cinnamon Desktop, Total Commander 9.21a 64-bit
Ubuntu 18.04.1 32-bit Mate Desktop, Total Commander 9.21a 32-bit
Windows? - 1 window in every room
When dealing with sensitive files a good philosophy is: never peek--not once--not ever., I completely blocked that entire part of the data gatherer because I don't want to ever see that data
and better yet, not have possesion of the data to begin with.
exactly. that data should never be collected, for any reason...
Mate desktop https://mate-desktop.org/
Debian non-free (including firmware) Live images
https://cdimage.debian.org/images/unoff ... e+nonfree/
anybody know that?