Mint Beta testers for the new inxi Perl release requested
Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Re: Mint Beta testers for the new inxi Perl release requested
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.
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
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?
- powerwagon75
- Level 4
- Posts: 338
- Joined: Sun Feb 28, 2016 4:05 pm
- Location: USA
Re: Mint Beta testers for the new inxi Perl release requested
I had updated yesterday morning, just prior to running the pinxi -zixxx. Updated just now, and ran again; now it is identifying "Card-2":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.........
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>
Custom Antec Outside tower w/Mint 20.2
HP lap w/Mint 20.3
Optiplex 960 "Frankenbox" w/Fedora 39/Mint 19.2/Mint 20.2
Advantech TPC-1551T w/LinuxLite
Acer C720 Chromebook w/GalliumOS
Mac PPC G4 w/Lubuntu
Re: Mint Beta testers for the new inxi Perl release requested
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
Re: Mint Beta testers for the new inxi Perl release requested
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,
In perl:
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.
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,
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.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:
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.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.
In perl:
Code: Select all
-t Filehandle is opened to a tty.
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
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.
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
that info is in /etc/apt/sources.listCosmo. 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.
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
Peter
Mate desktop https://wiki.debian.org/MATE
Debian GNU/Linux operating system: https://www.debian.org/download
Mate desktop https://wiki.debian.org/MATE
Debian GNU/Linux operating system: https://www.debian.org/download
Re: Mint Beta testers for the new inxi Perl release requested
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!
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-------------------Lenovo T440 - Manjaro KDE with Mint VMs
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Re: Mint Beta testers for the new inxi Perl release requested
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
Re: Mint Beta testers for the new inxi Perl release requested
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
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
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
Appreciate it! Testing here it seems to work as expected nowh2-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.
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!
Re: Mint Beta testers for the new inxi Perl release requested
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
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
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-------------------Lenovo T440 - Manjaro KDE with Mint VMs
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Re: Mint Beta testers for the new inxi Perl release requested
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.
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
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.
Re: Mint Beta testers for the new inxi Perl release requested
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.h2-1 wrote:BG405, you have to be precise, re showing actual examples of what you mean
Dell Inspiron 1525 - LM17.3 CE 64-------------------Lenovo T440 - Manjaro KDE with Mint VMs
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Toshiba NB250 - Manjaro KDE------------------------Acer Aspire One D255E - LM21.3 Xfce
Acer Aspire E11 ES1-111M - LM18.2 KDE 64 ----… Two ROMS don't make a WRITE …
Re: Mint Beta testers for the new inxi Perl release requested
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.
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.
inxi system information script (install info) :: inxi git
Re: Mint Beta testers for the new inxi Perl release requested
Hi h2-1, if you're still listening, I just updated to 2018-04-17 and noticed
but (just the audio section)
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
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
Re: Mint Beta testers for the new inxi Perl release requested
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 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.