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 » Wed Mar 21, 2018 12:16 am

powerwagon7, re your usb networking, did you update to latest pinxi for that one? The fix was added last night.

That is the exact bug I was hoping to have fixed, however, if no obvious usb device shows for networking in lsusb -v then inxi cannot figure out that it's a networking device, there is no identifier you can query that says, are you a networking device? I can dig into /sys and discover some info about the device, then back match it to lsusb data, which is a pain, but as it is now, if it couldn't see it as a networking device, it won't show, and the IF-ID will show instead.

=========================
all41, from my smxi work, I can tell you a few things about trying to find the age of a system. Short answer, you can't, it's a fantasy. I looked at every way, and it's not possible, it's a total illusion to believe you can. You can take crude guesses, but they are so often wrong that it's not even worth the effort. If you look inside smxi, you'll see one such funciton, which is not used, and hasn't been for many years, but I left it there just in case something ever turned up, but now I lost interest in that entire question because I did not view it as a good way to spend time.

So that method is out of the question. Possible solutions require querying clear files or data, not programs because pinxi is already running way too many subshell commands as it is, so it has to be a file.

Basically re such features, it comes down to this: if you can't tell me precisely how to get whatever data is needed that is specific to Mint, then inxi/pinxi cannot provide that data, since it has no brains of its own, and has to be told how to do that.

I can tell you that I had similar issues back when I was in various distro core teams, and after trying many times, I gave up, and never found a solution. The correct solution is for upgrades to install a machine readable file that allows a program to determine this type of thing, and that's more in mint's area than pinxi. If you do find this is an issue, then simply attach a small file to updates alongside some other package, that updates along with the package, then pinxi can read that file, but without that file, I feel quite confident in saying it cannot be done with any accuracy.

=========================

greerd, re the reported speed, that is a typical example of garbage data, that's the vendor's fault, not pinxi's, a very common situation, and not one I can really fix easily. Pinxi reads the speed listed, and dutifully reports it. However, in cases where you see: IF-ID-1 it means that inxi failed to get the usb device, and could not make a match with it correctly, so that data comes from a slightly different method, same place, but the data isn't different.

Again, I tried to fix that issue last night, so make sure you are using the latest pinxi to test it. I don't have a usb device of my own, just never got one, so it's hard to test, though I think I'll pick up a few in the future to make that easier to test.

=========================

phd21, I put -U on all my stuff, it's a feature I really like, that way I don't have to hassle with the url, remembering paths, etc.

Re the gfx driver issue, that's something I've seen in inxi output for years, and I've always been mystified by it, re the missing driver, but the samples you both showed were very helpful. My feeling is I should just ask the xorg guys to explain how that can happen, using your log file as an example. But it doesn't hurt to show -zv8 again after updating.

=========================

Pjotr, thank you for confirming, I researched this and it's a known issue with some decisions systemd made with their vm detection tool. However, basically it's simple, if it's Oracle, it's virtualbox, so I just switched the values in that case. Would have been nice if systemd had made the same choice, but they didn't.
Last edited by h2-1 on Sat Jun 16, 2018 5:50 pm, edited 1 time in total.

User avatar
thx-1138
Level 6
Level 6
Posts: 1138
Joined: Fri Mar 10, 2017 12:15 pm
Location: Athens, Greece

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

Post by thx-1138 » Wed Mar 21, 2018 6:17 am

h2-1, if i'm not bothering you with such questions (& possibly requests?), have you ever considered parsing some of the results from tune2fs -l, eg. like 'Filesystem created' etc? Or do you feel that such are not worth the inclusion & would only unnecessary further complicate things?

User avatar
powerwagon75
Level 3
Level 3
Posts: 170
Joined: Sun Feb 28, 2016 4:05 pm
Location: USA

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

Post by powerwagon75 » Wed Mar 21, 2018 6:59 am

h2-1 wrote:
Wed Mar 21, 2018 12:16 am
powerwagon75, re your usb networking, did you update to latest pinxi for that one? The fix was added last night.

That is the exact bug I was hoping to have fixed, however, if no obvious usb device shows for networking in lsusb -v then inxi cannot figure out that it's a networking device, there is no identifier you can query that says, are you a networking device? I can dig into /sys and discover some info about the device, then back match it to lsusb data, which is a pain, but as it is now, if it couldn't see it as a networking device, it won't show, and the IF-ID will show instead.........
I had updated yesterday morning, just prior to running the pinxi -zixxx. Updated just now, and ran again; now it is identifying "Card-2":

Code: Select all

$ sudo pinxi -zixxx
Network:   Card-1: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller driver: alx v: kernel port: d000 
           bus ID: 03:00 chip ID: 1969:e0a1 
           IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IP v4: <filter> type: dynamic enp3s0 scope: global broadcast: <filter> 
           IP v6: <filter> scope: link 
           Card-2: D-Link Wireless Adapter type: USB driver: rtl8812au bus ID: 1:2 chip ID: 2001:3315 
           IF: enx7062b8ab55d2 state: up mac: <filter> 
           IP v4: <filter> type: dynamic enx7062b8ab55d2 scope: global broadcast: <filter> 
           IP v6: <filter> scope: link 
           WAN IP: <filter> 
Thank you for all the hard work!
Image
Image

User avatar
xenopeek
Level 24
Level 24
Posts: 22882
Joined: Wed Jul 06, 2011 3:58 am
Location: The Netherlands

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

Post by xenopeek » Wed Mar 21, 2018 1:22 pm

It would be nice if pinxi would detect when it is outputting to a pipe and not use colors in that case unless enabled (like how many other commands work). So it can be piped to a paste service and if the user forgets to disable colors it doesn't end up looking like:

Code: Select all

[1;34mSystem:    [0m[1;34mHost:[0m mint [1;34mKernel:[0m 4.10.0-38-generic x86_64 [1;34mbits:[0m 64 [1;34mDesktop:[0m Cinnamon 3.6.6 [0m
           [1;34mDistro:[0m Linux Mint 18.3 Sylvia   [0m
Image

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 » Wed Mar 21, 2018 3:26 pm

thx-1138, n0, I hadn't considered it, but that's why I am looking for feedback, inxi already does everything and much more than I would have thought of, just the other day someone pointed out that the long time fake data for audio and network usb drivers was fake, and that it could be gotten from /sys, and we figured out how to do that. Wasn't my idea, and it was a good one. If you want to be more specific, give me an idea of what you think would be valuable in there. Note that this can only be used as root, which is generally something I try to avoid, but for extra data, probably -xxx in this case, that would be fine since the user knows it. Actually, I'm still getting used to the long options, it would be --partitions-deep or something like that. The one major downside is that it only covers ext234 file system types, which is fairly limiting, but also covers a lot of linux users. Taking a look at the output, there's obviously info that would be of interest to sys admins, like inode data, but not to most users. The block size could be useful. The mount count could be useful. LIfetime writes could be useful. File system creation could be interesting. Features in theory but they are so long they wouldn't really fit. State is of clear utility. That's the ones that jump out at me.

https://github.com/smxi/inxi/issues/134 I've started a Perl inxi new release issue that tracks these various observations I've gotten from the beta testers so far, since I won't remember them. Added yours to the list, but let me know more concretely what you'd want to see. Of the ones I listed, State is clearly the most important, mounts is relevant.

==============================

powerwagon75, I'm relieved to hear it, otherwise there would have been an unknown at work, and those are hard to figure out, good to see it there, thanks.

==============================

xenopeek,
It would be nice if pinxi would detect when it is outputting to a pipe and not use colors in that case unless enabled (like how many other commands work). So it can be piped to a paste service and if the user forgets to disable colors it doesn't end up looking like:
In the interest of not assuming something is impossible because I believe it isn't, I double checked this, and there is in fact a way for at least C to know this, sort of: https://unix.stackexchange.com/question ... or-printed. So while my initial reaction was to laugh, as with all questions where one does not know the answer for sure, it's worth checking into it. Now, this is C, which is a very low level, close to the OS language.
calling the C function isatty(STDOUT_FILENO). If output is anything else than a terminal (like a pipe or a file), it defaults to an output format that is more program-friendly.
So this is possible in C, but I have no idea if it's possible in Perl. However, I can check. Good question, I'm glad I checked on it before saying it was impossible, which what I was going to do, heh.

In perl:

Code: Select all

-t	Filehandle is opened to a tty.
However, the print output is not creating a file handle, so that won't be very useful. it's possible that only a very low level language like C can work at that advanced level, but Perl is actually quite low level as well and has been around a long time. I can ask this at perlmonks I think, it's beyond my understanding. I've added this question to the issue thread on github because it's a good one which I can't answer conclusively, thanks.

My strong suspicion is that Perl cannot do this because when a standard print to screen output is given, perl will not know the destination of that print action. But that's the question to be answered conclusively, not to be assumed.

http://www.perlmonks.org/?node_id=1063635 has this exact question.

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 » Wed Mar 21, 2018 4:34 pm

xenopeek, live and learn, another great suggestion. Never thought it possible, but its' a simple flag plus test.

Try: pinxi 2.9.02-03 to make sure it works, I tested it just now, if irc, does not do rule, if printing to screen, does not. over ssh, does not. Oh, wait, one scenario I did not test, an ssh command including the pinxi command, hmmm

writing to file removes colors, piping removes colors, so there is one scenario that needs to be tested.

User avatar
sdibaja
Level 5
Level 5
Posts: 635
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 » Wed Mar 21, 2018 4:37 pm

Cosmo. wrote:
Tue Mar 20, 2018 5:57 pm
Not a bug report, but a feature request:

Can you add the information, if the current version of Mint (as we are here in the Mint forum) is a fresh install or an upgrade?

In some cases this information can be crucial and specially the changes in the Mint 18.x series, which only partially get applied, if the system has been upgraded, makes this desirable.

The ideal case would be, if inxi could tell, which version had originally been installed, but I fear, this is likely impossible to find out. But even the information, when the system had been installed at first (discovered by the age of some system files), would be of some help. So if inxi says, that a given system runs Mint 18.3, but we can see also, that the system does exist at least for, lets say, 5 months, than we know, that the system had been installed with a previous version.
that info is in /etc/apt/sources.list
open it with your favorite text editor, not the default GUI

Code: Select all

# deb cdrom:[Official Debian GNU/Linux Live 9.3.0 mate 2017-12-09T13:26]/ stretch main

# deb cdrom:[Official Debian GNU/Linux Live 9.3.0 mate 2017-12-09T13:26]/ stretch main

User avatar
BG405
Level 6
Level 6
Posts: 1424
Joined: Fri Mar 11, 2016 3:09 pm
Location: England

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

Post by BG405 » Wed Mar 21, 2018 4:39 pm

Installing on my systems & will test it. :)

No man page appears to be present but the --help is very comprehensive. Have saved a copy in my Linux Documentation collection for easy reference.

As a regular user of inxi I appreciate the work that goes in to this, thanks!
Dell Inspiron 1525 - LM17.3 CE 64-------------------Acer D255E 2GB - Manjaro KDE, LM17.3 KDE 32
Toshiba NB305 - Manjaro KDE------------------------K7S5A AMD 1.2GHz - LM17.3 Xfce 32 & WinXP-Pro
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----Dell PII 350 64MB - Puppy 4.3 & Win98-SE

User avatar
greerd
Level 5
Level 5
Posts: 981
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 » Wed Mar 21, 2018 4:50 pm

all41 wrote:
Tue Mar 20, 2018 7:23 pm
@phd21
Regarding updating--
sudo inxi -U
has always been the case.
This is not the case for me:

Code: Select all

sudo inxi -U
Error 17: All inxi self updater features have been disabled by the distribution
package maintainer. This includes the option you used: -U

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 » Wed Mar 21, 2018 4:59 pm

sdibaja, that's a good example of a file, easy to read. Now, where do you want to see this output in inxi? exactly. I'm working on inxi 2.9.03 now.

Show a sample using: distro: ..... and put the exact part of that you want to see, or it could be its own item, like: distro: mint.... something: more info
or: distro: mint... more info

User avatar
xenopeek
Level 24
Level 24
Posts: 22882
Joined: Wed Jul 06, 2011 3:58 am
Location: The Netherlands

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

Post by xenopeek » Wed Mar 21, 2018 5:03 pm

h2-1 wrote:
Wed Mar 21, 2018 4:34 pm
xenopeek, live and learn, another great suggestion. Never thought it possible, but its' a simple flag plus test.

Try: pinxi 2.9.02-03 to make sure it works, I tested it just now, if irc, does not do rule, if printing to screen, does not. over ssh, does not. Oh, wait, one scenario I did not test, an ssh command including the pinxi command, hmmm

writing to file removes colors, piping removes colors, so there is one scenario that needs to be tested.
Appreciate it! Testing here it seems to work as expected now :)

When I don't use the -c option piping or redirecting output it doesn't display color codes. When I do explicitly set the color theme with -c it does output color codes even when piping or redirecting output. Perfect!
Image

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 » Wed Mar 21, 2018 5:06 pm

greerd, distro maintainers have the option to create a configuration setting that disables user updates. You can always tell if this is active or not by looking at the help menu, if it shows the -U option, it isn't, if it doesn't, it is.

You can change this setting in /etc/inxi.conf changing B_ALLOW_UPDATE to true
Last edited by h2-1 on Wed Mar 21, 2018 5:15 pm, edited 2 times in total.

User avatar
BG405
Level 6
Level 6
Posts: 1424
Joined: Fri Mar 11, 2016 3:09 pm
Location: England

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

Post by BG405 » Wed Mar 21, 2018 5:06 pm

Historical version info = great idea. I'd suggest just basic info on (possibly estimated) install date at the top (System) & an option to show full details? :)
Dell Inspiron 1525 - LM17.3 CE 64-------------------Acer D255E 2GB - Manjaro KDE, LM17.3 KDE 32
Toshiba NB305 - Manjaro KDE------------------------K7S5A AMD 1.2GHz - LM17.3 Xfce 32 & WinXP-Pro
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----Dell PII 350 64MB - Puppy 4.3 & Win98-SE

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 » Wed Mar 21, 2018 5:12 pm

BG405, you have to be precise, re showing actual examples of what you mean, remember, I have zero knowledge about what parts of that string are important to you. Also, if variable amounts of output, which bits at which amounts. Show a few examples in the exact format inxi uses in distro: section. I could add a second key there for example if say, extra data -x, and mint. I don't want to get into too much distro specific stuff because that's a headache to maintain, and assumes stuff will remain the same, which it never does, but if it's clear and obvious, and not too hard to do, I can add it in this case, but remember, that implies this data structure does not change.

The real place this should have been put is in either lsb-release or os-release files in /etc, they have a variety of fields that can be used for such data.

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 » Wed Mar 21, 2018 5:20 pm

xenopeek, while that latter 'feature' of showing them the color when using -c might be nifty, don't give me credit there, lol, that was not intended, in fact it's a bug since it was supposed to be an absolute override. But looking at the color setting logic, that's right, because the color setter only hits when a color was not set with -c. So that might work ok. However, it seems logical that if a user uses -c they want to see -c, so to speak.

User avatar
xenopeek
Level 24
Level 24
Posts: 22882
Joined: Wed Jul 06, 2011 3:58 am
Location: The Netherlands

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

Post by xenopeek » Wed Mar 21, 2018 5:34 pm

It's pretty common for programs and scripts that default to use color to only use color if stdout is connected to a terminal or the user explicitly says to use color regardless. Like how pinxi now functions. Might not be intentional but makes the most sense to me.
Image

User avatar
BG405
Level 6
Level 6
Posts: 1424
Joined: Fri Mar 11, 2016 3:09 pm
Location: England

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

Post by BG405 » Wed Mar 21, 2018 5:48 pm

h2-1 wrote:BG405, you have to be precise, re showing actual examples of what you mean
I'm happy to do that once I've had a proper look (a bit too noisy to concentrate in here properly!) hopefully tonight before I sleep. Sorry was in a bit of a hurry earlier when I posted.
Dell Inspiron 1525 - LM17.3 CE 64-------------------Acer D255E 2GB - Manjaro KDE, LM17.3 KDE 32
Toshiba NB305 - Manjaro KDE------------------------K7S5A AMD 1.2GHz - LM17.3 Xfce 32 & WinXP-Pro
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----Dell PII 350 64MB - Puppy 4.3 & Win98-SE

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 » Wed Mar 21, 2018 6:00 pm

BG405, just imagine you are pinxi, or me, who knows nothing, and can only do what you are told to do, follow the rules you are given.

Currently the distro line receives 1 bit of data, the distro string. You don't want that string made a whole lot longer, so I believe what I would do is return an array, not a single value, for all non mint distros, that array would have 1 element, for mint, it would have two, the second bit would be the extra data.

So it would say:

distro: [Mint release...] extra: [the stuff you want to see]

If the data was empty, for all distros, including mint, it would not show extra:

technically I think that's how I'd do it, because the distro string is already too long. The 'extra:' is nice and neutral, and -x levels could determine what it shows. That's roughly what I would recommend, but again, the data source is what I consider junk data, because it's a text file anyone can edit, the next mint could change it, and that type of data in my experience is super unreliable, and not something that should be depended on. As I indicated, the proper solution for mint is to create a small file that nobody touches and which is not connected to anything else, or to add a field to os-release or lsb-release, whichever mint uses, and put the data there, that way it's reliable and not a hack that will break in the future. This is my experience anyway.

User avatar
greerd
Level 5
Level 5
Posts: 981
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 » Sun Apr 22, 2018 8:44 pm

Hi h2-1, if you're still listening, I just updated to 2018-04-17 and noticed sudo pinxi -Axx dosen't show my AudioQuest DragonFly while sudo pinxi -Fxz does. I don't know if this was the case before.

Code: Select all

sudo pinxi -Axx
Audio:
  Card-1: Intel 82801JI HD Audio driver: snd_hda_intel v: kernel 
  bus ID: 00:1b.0 chip ID: 8086:3a3e 
  Card-2: NVIDIA GM204 High Definition Audio driver: snd_hda_intel v: kernel 
  bus ID: 08:00.1 chip ID: 10de:0fbb 
  Card-3: N/A type: USB driver: snd-usb-audio bus ID: 9:3 chip ID: 21b4:0082 
  Sound Server: ALSA v: k4.4.0-119-generic 
but (just the audio section)

Code: Select all

sudo pinxi -Fxz
...
Audio:
  Card-1: Intel 82801JI HD Audio driver: snd_hda_intel v: kernel 
  bus ID: 00:1b.0 
  Card-2: NVIDIA GM204 High Definition Audio driver: snd_hda_intel v: kernel 
  bus ID: 08:00.1 
  Card-3: AudioQuest DragonFly Red v1.0 type: USB driver: snd-usb-audio 
  bus ID: 9:3 
  Sound Server: ALSA v: k4.4.0-119-generic 
...
  pinxi: 3.0.07-1 

Cosmo.
Level 23
Level 23
Posts: 17829
Joined: Sat Dec 06, 2014 7:34 am

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

Post by Cosmo. » 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.

Post Reply

Return to “Chat about Linux”