Mint Beta testers for the new inxi Perl release requested

Chat about Linux in general
h2-1
Level 3
Level 3
Posts: 186
Joined: Sat Oct 16, 2010 4:02 pm
Contact:

Re: Mint Beta testers for the new inxi Perl release requested

Post by h2-1 » Thu Jun 14, 2018 4:42 pm

As you can probably see, no, I wasn't checking this thread much anymore. But pinxi is alive and well, and was promoted to permanent inxi development version, now at pinxi 3.0.12-16.

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.

User avatar
greerd
Level 5
Level 5
Posts: 986
Joined: Sat Jul 31, 2010 10:58 am
Location: Nova Scotia, Canada

Re: Mint Beta testers for the new inxi Perl release requested

Post by greerd » Thu Jun 14, 2018 8:44 pm

Hi h2-1

Still the same issue regarding usb audio, ran pinxi --debug 22 as normal user and again with sudo. The files sent are pinxi-mint19-dt-2018-06-14_213733-3.0.12.tar.gz and with sudo pinxi-mint19-dt-2018-06-14_214107-3.0.12.tar.gz.

Cheers

h2-1
Level 3
Level 3
Posts: 186
Joined: Sat Oct 16, 2010 4:02 pm
Contact:

Re: Mint Beta testers for the new inxi Perl release requested

Post by h2-1 » Thu Jun 14, 2018 9:15 pm

greerd, glad I asked for the debugger data set, otherwise I would have been sad and confused, lol.

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.

User avatar
greerd
Level 5
Level 5
Posts: 986
Joined: Sat Jul 31, 2010 10:58 am
Location: Nova Scotia, Canada

Re: Mint Beta testers for the new inxi Perl release requested

Post by greerd » Fri Jun 15, 2018 6:12 pm

Thanks for the explanation and for inxi itself, a very handy program.

h2-1
Level 3
Level 3
Posts: 186
Joined: Sat Oct 16, 2010 4:02 pm
Contact:

Re: Mint Beta testers for the new inxi Perl release requested

Post by h2-1 » Fri Jun 15, 2018 8:45 pm

Cosmo. wrote:
Mon Apr 23, 2018 6:03 am
In 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 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.

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
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.

Mint 19

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
Mint 18

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
Mint 17

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/"

lmuserx4849

Re: Mint Beta testers for the new inxi Perl release requested

Post by lmuserx4849 » Fri Jun 29, 2018 3:24 pm

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.
..
This might of been answered in the thread, but just in case:

LM 17.3 - /etc/os-release
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/"
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.

Does techpatterns have a privacy policy? Who can see this data? Is it used for other purposes, other than debugging pinxi?

It would be nice, if pinxi had a Confirmation Message before uploading any data.

Nice job on the perl.

h2-1
Level 3
Level 3
Posts: 186
Joined: Sat Oct 16, 2010 4:02 pm
Contact:

Re: Mint Beta testers for the new inxi Perl release requested

Post by h2-1 » Fri Jun 29, 2018 4:39 pm

who can see it? me. Period, nobody else. I might show specific files that are neutral re sys info to people working on a feature, but that's it, it's my server, nobody can access it, and nobody but me sees that data. Technically a weak point of inxi dev because the datasets are an ultra core part of feature development in inxi, but there's no way to use those publicly in my opinion without doing a lot of cleanup and filter work which I don't feel like doing. So I'm it, the only eyes to see it.

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.

User avatar
karlchen
Level 19
Level 19
Posts: 9420
Joined: Sat Dec 31, 2011 7:21 am
Location: Germany

Re: Mint Beta testers for the new inxi Perl release requested

Post by karlchen » Sat Jun 30, 2018 8:38 am

Hi, h2-1.

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".

Best regards,
Karl
Image
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

User avatar
all41
Level 13
Level 13
Posts: 4847
Joined: Tue Dec 31, 2013 9:12 am
Location: Computer, Car, Cage

Re: Mint Beta testers for the new inxi Perl release requested

Post by all41 » Sat Jun 30, 2018 8:21 pm

, I completely blocked that entire part of the data gatherer because I don't want to ever see that data
When dealing with sensitive files a good philosophy is: never peek--not once--not ever.
and better yet, not have possesion of the data to begin with.
Proud to be a supporter and monthly contributor to Mint.

User avatar
sdibaja
Level 5
Level 5
Posts: 666
Joined: Sun May 08, 2011 12:57 pm
Location: Baja California, Mexico

Re: Mint Beta testers for the new inxi Perl release requested

Post by sdibaja » Sat Jun 30, 2018 8:34 pm

all41 wrote:
Sat Jun 30, 2018 8:21 pm
, I completely blocked that entire part of the data gatherer because I don't want to ever see that data
When dealing with sensitive files a good philosophy is: never peek--not once--not ever.
and better yet, not have possesion of the data to begin with.
exactly. that data should never be collected, for any reason...

h2-1
Level 3
Level 3
Posts: 186
Joined: Sat Oct 16, 2010 4:02 pm
Contact:

Re: Mint Beta testers for the new inxi Perl release requested

Post by h2-1 » Sat Jun 30, 2018 9:43 pm

Exactly, that's why I removed it completely as soon as I realized what was happening, that only happened in pinxi testing of this feature. What I would like to know is why this particular thing is even happening in /proc in the first place. It's too difficult to explain what or how it happens, but it's something that is a clear oversight by the kernel guys because /proc has no business even exposing that data. Luckily it's very easy to filter those files out, so I did.

User avatar
all41
Level 13
Level 13
Posts: 4847
Joined: Tue Dec 31, 2013 9:12 am
Location: Computer, Car, Cage

Re: Mint Beta testers for the new inxi Perl release requested

Post by all41 » Sat Jun 30, 2018 9:50 pm

such as a poker game no-peeky
anybody know that?
Proud to be a supporter and monthly contributor to Mint.

Post Reply

Return to “Chat about Linux”