Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Beta testers for new Perl inxi requested

If none of the specific sub-forums seem right for your thread, ask here.
Message
Author
h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#46 Post by h2 »

Code: Select all

Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
Darn it!!

Now I see. Alpine, who do not write clang, decided they should put their distro name in the string, which is downright absurd. Tough to fix in pinxi, because it expects, quite reasonably that program version strings will be what they are.

Hmm, I know, I'll add in one more test, if the value received is version, increment the snip by 1.

That may work, since most cases I've seen now that are wrong are the result of people adding in a word before the actual application name, which almost never happens, but I've seen enough cases now where I think that fix is the best I'll try, and I think it will fix that class of errors.

Thanks for these examples of yet more fringe cases, these have been enormously helpful, much appreciated.

Will fix this in 0454, that's a pretty easy regex check. It will work in most cases where this type of string add was made, and version was teh found term, and I think I'll draw the line there, after that, it's really outside of the scope of pinxi in my opinion.

Actually, now I'm confused, pinxi is already snipping out the 4th item. hmm. I just realized, this was a fix I did to try to fix the wrong clang version line, so I have to revert that, and then add in the snip increment check.

Code: Select all

# freebsd
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-freebsd10.3
Thread model: posix

#another freebsd
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-freebsd10.3
Thread model: posix

# linux
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /sbin
You'll notice that the last one is the same exact release as the Alpine labeled one, and, worse, by putting their name first, before the actual program name. The only reason pinxi caught this at all was that it wasn't looking for the string ^clang, starter, but just clang. This means alpine just wanted to be 'special' as far as I can tell, by claiming credit for a program they didn't write. The obvious and correct place to have put any specifics in that string would either be appended to the actual version number, or in the (). this is why I really by the way like Debian, they don't mess around like this.

MY basic inclination in such cases is to file a bug report against alpine clang, and tell them to get rid of their name in that position, but pinxi will try to handle it since there's no telling when people will do things like this.

The init stuff I'd really like to solve however, I'm trying to get some data on that to see what's up. I think it's fixable.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#47 Post by h2 »

By the way, as an example of what pinxi output looks like when i have direct machine access, this is one of the remote FreeBSD servers I developed pinxi on. Much to my great fortune, the hoster here actually updated their FreeBSD version about 1/2 way through the development process, so I was able to develop early pinxi on Perl 5.010, 5.012, and I think 5.014 maybe. Plus the local system I have that runs Perl 5.008, a venerable Debian stable.

Code: Select all

pinxi -zv8 --alt 31
System:    Kernel: FreeBSD 10.3-RELEASE-p13 amd64 bits: 64 compiler: clang v: 3.4.1 Console: tty 1 dm: N/A 
           OS: FreeBSD 10.3-RELEASE-p13 
Machine:   Permissions: Unable to run dmidecode. Are you root? 
Battery:   Permissions: Unable to run dmidecode. Are you root? 
Memory:    RAM Report: permissions: Unable to run dmidecode. Are you root? 
PCI Slots: Permissions: Unable to run dmidecode. Are you root? 
CPU:       Topology: 8 Core model: Intel Core i7 930 type: MCP arch: N/A L2 cache: N/A 
           features: dmesg.boot permissions 
           Speed: 2800 MHz min/max: 1600/2801 MHz Core speeds: 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 
Graphics:  Card-1: Matrox Systems MGA G200eW WPCM450 driver: vgapci bus ID: 0:8:4.0 chip ID: 102b:0532 
           Display Server: No display server data found. Headless server? tty: 131x52 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Message: No PCI card data found. 
Network:   Card-1: Intel 82574L Gigabit Network Connection driver: em port: N/A bus ID: 0:6:0 
           chip ID: 8086:10d3 
           IF: em0 state: active speed: 1000baseT duplex: full-duplex mac: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v6: <filter> scope: link 
           IP v6: <filter> scope: N/A 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           Message: Output throttled. IPs: 458; Limit: 10; Override: --limit [1-x;-1 all] 
           Card-2: Intel 82574L Gigabit Network Connection driver: em port: N/A bus ID: 0:7:0 
           chip ID: 8086:10d3 
           IF: em1 state: no mac: <filter> 
           WAN IP: <filter> 
Drives:    HDD Total Size: dmesg.boot permissions used: 603.60 GB 
           Drive Report: dmesg.boot permissions 
           Optical Report: dmesg.boot permissions 
RAID:      Device-1: tank type: zfs status: ONLINE size: 1.81 TB free: 1.18 TB allocated: 651.00 GB 
           size: 1.81 TB free: 1.18 TB allocated: 651.00 GB components: online: ada2 ada1 ada3 
           Device-2: cache type: zfs status: no-status raid: no-raid size: 25.90 GB free: 8.14 GB components: 
           online: ada0s2 
Partition: ID-1: / size: 53.27 GB used: 26.79 GB (50.3%) fs: ufs dev: /dev/ada0s1a label: N/A uuid: N/A 
           ID-2: /usr/boxes size: 1.39 TB used: 271.74 GB (19.2%) fs: zfs raid: tank/boxes label: N/A uuid: N/A 
           ID-3: /usr/home size: 1.24 TB used: 124.56 GB (9.8%) fs: zfs raid: tank/home label: N/A uuid: N/A 
           ID-4: /usr/public_ftp size: 1.12 TB used: 2.49 GB (0.2%) fs: zfs raid: tank/public_ftp label: N/A 
           uuid: N/A 
           ID-5: /usr/www/users size: 1.26 TB used: 142.92 GB (11.1%) fs: zfs raid: tank/www-users label: N/A 
           uuid: N/A 
           ID-6: /usr/wwws/users size: 1.12 TB used: 35 KB (0.0%) fs: zfs raid: tank/wwws-users label: N/A 
           uuid: N/A 
           ID-7: /var/mail size: 1.15 TB used: 31.95 GB (2.7%) fs: zfs raid: tank/var-mail label: N/A uuid: N/A 
           ID-8: swap-1 size: 5.00 GB used: 3.16 GB (63.2%) fs: swap dev: /dev/ada0s1b label: N/A uuid: N/A 
Unmounted: Message: No unmounted partition data found for this BSD system. 
USB:       Missing: Required tool usbdevs not installed. Check --recommends 
Sensors:   Platform: No Freebsd support. Is a comparable sensors tool available? 
Repos:     BSD ports server: /etc/portsnap.conf 
           1: portsnap.FreeBSD.org
           FreeBSD update server: /etc/freebsd-update.conf 
           1: update.FreeBSD.org
           BSD enabled pkg servers in: /etc/pkg/FreeBSD.conf 
           1: pkg+http://pkg.FreeBSD.org/$ABI/quarterly
Processes: CPU  % used - Command - pid - Memory: MB / % used - top: 5 (only 4 processes) 
           1: cpu: 0.0% command: sshd: pid: 82509 mem: 5.94MB (0.0%) 
           2: cpu: 0.0% command: pinxi started by: perl pid: 28188 mem: 18.9MB (0.1%) 
           3: cpu: 0.0% command: ps pid: 28193 mem: 1.76MB (0.0%) 
           4: cpu: 0.0% command: -csh pid: 82514 mem: 2.91MB (0.0%) 
           Memory MB/% used - Command - pid - CPU: % used - top: 5 (only 4 processes) 
           1: mem: 18.9 MB (0.0%) command: pinxi started by: perl pid: 28188 cpu: 0.1% 
           2: mem: 5.94 MB (0.0%) command: sshd: pid: 82509 cpu: 0.0% 
           3: mem: 2.91 MB (0.0%) command: -csh pid: 82514 cpu: 0.0% 
           4: mem: 1.76 MB (0.0%) command: ps pid: 28193 cpu: 0.0% 
Info:      Processes: 4 Uptime: 20 days Memory: 23.98 GB used: 23.74 GB (99.0%) Init: init (BSD) v: N/A 
           Compilers: gcc: 6.4.0 clang: 3.7.1 Shell: csh 6.18.01 running in: tty 1 pinxi: 2.9.00-454-p
As you can see, except for a few root access requiring features, it's basically complete.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#48 Post by h2 »

Barring last minute tonite or tomorrow morning bug fixes, inxi will go to 2.9.01 tomorrow, which will end the pinxi development branch for now.

I may do one or two more pinxi patch releases if I find something at the last minute, but otherwise, I'm calling it good, I can't spend more time on the beta/dev phase, work beckons.

when it hits distros is up to maintainers, but that will instantly close all pre 2.9 support, since I don't support legacy versions of inxi.

thanks for the great issues, there's a few things I saw that are not fixed yet, but that's mainly because i did not get requested data and I can't fix stuff blindly, so I'm leaving those as things people can file issues on github inxi after tomorrow.

As they say, the perfect in software is the enemy of the good, and pinxi is WAY better than inxi is now, so I feel fine about jumping it up now even if has some glitches, those can be ironed out over the 2.9.xx release cycle.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: Beta testers for new Perl inxi requested

#49 Post by debiman »

h2 wrote:someone on IRC mocked my belief that arm would be consistent, so they'll get a chuckle from your example.
i also had to learn it the hard way.
i'm not in the habit of buying arm laptops.
that's the entire proc/cpuinfo I take it?, no edits?
yep, no edits.

i'll say it again, if you want to get more out of ARM machines you should look at armbian's motd script(s).
they support a long list of devices.

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#50 Post by h2 »

https://github.com/pfoo/armbian-lib/blo ... /armhwinfo that has some things in it, but not much more than pinxi shows for hardware, since I just added the /proc/cpuinfo, but I'll take a look at their other scripts and see if I can find more.

I'm fairly happy with most of pinxi now, and while I could basically do pinxi full time, nobody pays me to, so I have to stop at some point, which is actually now, after adding support for deb822 repo syntax in repos, by request of the ubuntu/debian packager (how can I say no to him?), the very last pinxi release I'll do, moving to inxi now.

Had to draw a dev line somewhere, I've been doing this stuff for months, literally.

thanks for the armbian script tips, I'll store those away and see if I can find any subtle little things. But to me, looking at, it's basically just assigning some key words to the device hardware based on the strings it finds, maybe that means more to arm users than me? probably so, so I'll probably add some of those things in the future.

Your arm laptop, being an actual thing that exists, did prompt me to try to get at least some hardware id for arm, and now it does, but only if /proc/cpuinfo has it.

Going to switch inxi to perl now.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#51 Post by h2 »

Just as an update, the pinxi branch has been promoted to the permanent development branch for inxi, making pinxi sort of like sid, and inxi sort of like testing, rolling along. And binxi is old stable, sitting unused and not updated.

I found the pinxi / inxi names allowed for very easy testing and verifications, so I'm keeping that going forwards.

In other words, pinxi will generally be right with inxi, or ahead of it, just like sid and testing, roughly.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#52 Post by h2 »

Testing in OpenBSD, with Perl, $KSH_VERSION does not get recognized inside of Perl. Its' in the shell, but not present as an environmental value that Perl can access. I suspected this would be the case, and it is.

did fix a bug that kept the openbsd specific stuff from running, which resulted in that shortened and buggy openbsd output I saw, so that's a very good start.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

Post Reply