Beta testers for Perl inxi requested

mralk3 · 03-16-2018, 07:06 PM

Are you referring to the following?

perl-JSON-XS

I installed that and its dependencies on a Slackware-current box and ran:

Code:

perl pinxi --output json --output-file /tmp/output.log

I received the following error:

Code:

Error 80: The required json export Perl module is not installed:
Cpanel::JSON::XS

mralk3 · 03-16-2018, 07:17 PM

A SlackBuild might need to be written and submitted to SlackBuilds.org if that is the wrong one. I will be happy to do so.

h2-1 · 03-16-2018, 07:34 PM

perl-JSON-XS is what Cpanel::JSON::XS was forked from, the one you installed is a different one, the original version, so it's not the wrong one per se, just a different one.

https://metacpan.org/pod/Cpanel::JSON::XS

You can always just use cpan to install it, that's easy, but if it's not in slackbuilds, it would be nice to provide it for slackware users anyway since it's the recommended version from what I gather.

In 2.9.00-0435-p I added the relatively crude and basic

Code:

XML::Dumper

because it was as easy to implement quickly as the json one, but it's output is far inferior unfortunately, but it is xml, and it does work, and it was easy, so I'll leave a nicer xml output for later days.

I'd hoped these would be easy using modules. pinxi currently does not offer slackpkg --recommends package install names, mainly because I don't have them, and inxi's version of this wasn't flexible enough to readily add different package managers.

If you scroll down the file to: sub item_data { then down to the program/modules sections, you can see where the slackpkg names would go, and I'd just use the same ID method that -repos uses to determine it's slackpkg. Slackware has always held a special spot in the gnu/linux world due to its commitment to clean uncluttered Linux as far as I'm concerned, even though I don't use it personally, I admire it.

By the way, pinxi supports FreeBSDs as well, though it's not feature complete, sometimes because the data just isn't there, sometimes because I haven't had time to do it. With pinxi extending bsd support has been much easier, so I have added more features already.

Loomx · 03-18-2018, 01:54 AM

Quote:

pinxi currently does not offer slackpkg --recommends package install names, mainly because I don't have them

Neither does slackpkg...

Cool tool though, I remember inxi fondly from using Debian.

Quote:

Slackware has always held a special spot in the gnu/linux world due to its commitment to clean uncluttered Linux as far as I'm concerned, even though I don't use it personally, I admire it.

That's how to win friends and influence people right there :-)

zakame · 03-18-2018, 05:48 AM

Quote:

Originally Posted by h2-1

perl-JSON-XS is what Cpanel::JSON::XS was forked from, the one you installed is a different one, the original version, so it's not the wrong one per se, just a different one.

I'd probably recommend looking into the Mojo toolkit also for a few reasons:

Mojo::JSON instead of {,Cpanel::}JSON{,::XS}
Mojo::DOM can be used as a lightweight XML parser/selector (no need for XS)
Mojo can build with no other CPAN dependencies, only optional ones for e.g. SSL and event loops

rokytnji · 03-18-2018, 01:17 PM

Bump

Code:

$ pinxi -v8
System:    Host: biker Kernel: 4.15.5-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 6.3.0 
           Desktop: IceWM 1.4.2 dm: slim Distro: antiX-17_x64-full Heather Heyer 24 October 2017 
Machine:   Type: Laptop System: Dell product: Latitude E4310 v: 0001 serial: N/A Chassis: type: 9 serial: N/A 
           Mobo: Dell model: 0T6M8G v: A01 serial: N/A BIOS: Dell v: A03 date: 07/08/2010 
Battery:   BAT-0: charge: 48.8 Wh condition: 40.3/48.8 Wh (82%) volts: 12.4/11.1 
           model: Samsung SDI DELL RM6618A type: Li-ion serial: N/A status: Full 
Memory:    RAM Report: permissions: Unable to run dmidecode. Are you root? 
PCI Slots: Permissions: Unable to run dmidecode. Are you root? 
CPU:       Topology: Dual Core model: Intel Core i5 M 520 type: MT MCP arch: Nehalem rev: 5 L2 cache: 3072 KB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19151 
           Speed: 1550 MHz min/max: 1199/2400 MHz Core speeds: 1: 1273 2: 1361 3: 1372 4: 1330 
Graphics:  Card-1: Intel Core Processor Integrated Graphics Controller driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:0046 
           Display Server: X.Org 1.19.2 driver: intel resolution: 1366x768~60Hz 
           OpenGL: renderer: Mesa DRI Intel Ironlake Mobile version: 2.1 Mesa 13.0.6 direct render: Yes 
Audio:     Card-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 chip ID: 8086:3b57 
           Sound Server: ALSA v: k4.15.5-antix.1-amd64-smp 
Network:   Card-1: Intel 82577LM Gigabit Network Connection driver: e1000e v: 3.2.6-k port: 6040 bus ID: 00:19 
           chip ID: 8086:10ea 
           IF: eth0 state: down mac: 5c:26:0a:06:32:15 
           Card-2: Intel Centrino Advanced-N 6200 driver: iwlwifi v: kernel bus ID: 02:00 chip ID: 8086:422c 
           IF: wlan0 state: up mac: 00:27:10:6a:ae:60 
           IP v4: 192.168.254.67/24 scope: global broadcast: 192.168.254.255 
           IP v6: fe80::227:10ff:fe6a:ae60/64 scope: link 
           WAN IP: 98.18.1.55 
Drives:    HDD Total Size: 55.90 GB used: 23.62 GB (42.3%) 
           ID-1: /dev/sda model: KINGSTON_SV300S3 size: 55.90 GB serial: 50026B7743028DAC rev: BBF0 
           Optical-1: /dev/sr0 vendor: TSSTcorp model: DVD+-RW TS-U633F rev: D500 dev-links: cdrom 
           Features: speed: 24 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram 
           state: running 
RAID:      Message: No RAID data was found. 
Partition: ID-1: / size: 7.63 GB used: 3.56 GB (46.7%) fs: ext4 dev: /dev/sda2 label: rootantiX 
           uuid: 78252287-6dbf-4719-9c7f-13d6bbc8143b 
           ID-2: /home size: 47.08 GB used: 20.06 GB (42.6%) fs: ext4 dev: /dev/sda1 label: homeantiX 
           uuid: 62a4a2cd-066a-47d3-a366-f8059a89cbcb 
Unmounted: Message: No unmounted partitions found. 
USB:       Hub: 1:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 1:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020 
           Hub: 2:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 2:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020 
           Device-1: Dell DW375 Bluetooth Module bus ID: 2:3 usb: 2.00 type: Bluetooth chip ID: 413c:8187 
           Device-2: Broadcom BCM5880 Secure Applications Processor with fingerprint swipe sensor bus ID: 2:4 
           usb: 1.10 type: Application Specific Interface chip ID: 0a5c:5801 
Sensors:   System Temperatures: cpu: 52.0 C mobo: N/A 
           Fan Speeds (in RPM): cpu: 0 
Repos:     Active apt sources in: /etc/apt/sources.list.d/antix.list 
           1: deb http://repo.antixlinux.com/stretch stretch main nosystemd
           Active apt sources in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
           Active apt sources in: /etc/apt/sources.list.d/debian.list 
           1: deb http://ftp.us.debian.org/debian/ stretch main contrib non-free
           2: deb http://security.debian.org/ stretch/updates main contrib non-free
           No apt repos found in: /etc/apt/sources.list.d/onion.list 
           No apt repos found in: /etc/apt/sources.list.d/various.list 
Processes: CPU  % used - Command - pid - Memory: MB / % used - top: 5 
           1: cpu: 62.3% command: firefox-esr pid: 5882 mem: 682.4MB (8.6%) 
           2: cpu: 1.9% command: xorg pid: 2292 mem: 38.1MB (0.4%) 
           3: cpu: 0.4% command: conky pid: 2664 mem: 10.5MB (0.1%) 
           4: cpu: 0.3% command: lxterminal pid: 12734 mem: 24.7MB (0.3%) 
           5: cpu: 0.2% command: python pid: 2297 mem: 15.4MB (0.1%) 
           Memory MB/% used - Command - pid - CPU: % used - top: 5 
           1: mem: 682.4 MB (62.3%) command: firefox-esr pid: 5882 cpu: 8.6% 
           2: mem: 41.3 MB (0.0%) command: python pid: 2602 cpu: 0.5% 
           3: mem: 38.1 MB (1.9%) command: xorg pid: 2292 cpu: 0.4% 
           4: mem: 27.8 MB (0.0%) command: volumeicon pid: 2590 cpu: 0.3% 
           5: mem: 24.7 MB (0.3%) command: lxterminal pid: 12734 cpu: 0.3% 
Info:      Processes: 155 Uptime: 3:17 Memory: 7.72 GB used: 878.6 MB (11.1%) Init: SysVinit v: 2.88 
           runlevel: 5 default: 5 Compilers: gcc: 6.3.0 alt: 6 Shell: bash 4.4.12 running in: lxterminal 
           pinxi: 2.9.00-444-p 
@biker:~
$ sensors
dell_smm-virtual-0
Adapter: Virtual device
Processor Fan:    0 RPM
CPU:            +52.0°C  
SODIMM:         +46.0°C  
Other:          +51.0°C  
Other:          +56.0°C  

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +53.0°C  (high = +95.0°C, crit = +105.0°C)
Core 2:       +50.0°C  (high = +95.0°C, crit = +105.0°C)

h2-1 · 03-18-2018, 01:56 PM

zakame, I'll take a look at those mojo ones. I was following perl maven's advice on the json one, but I'm not wedded to it. The xml::dump one was just the first xml generator I found that was easy to implement, but I don't like it's output that much.

rokytnji, that Other value is hard to know what to do with, it seems like it's either a gpu sensor that has not been labelled, or another cpu sensor. That temp is too high for a mobo sensor I believe, so it's not mobo. The SODIMM was supposed to be added, I'll check why it's not.

h2-1 · 03-18-2018, 04:38 PM

zakame, my initial look into the mojo toolkit appears negative, for example, I don't see an apt package for just Mojo::JSON module, only the full collection of mojo tools, which is serious overkill to get a single module installed. Both of the modules I picked do not I believe require further modules, but I'll confirm that. One of the core requirements I have for inxi/pinxi is to keep recommends and dependencies to an absolute barebones minimum.

I'll test on a few systems with barebones Perl installations, to see what either the Cpanel::JSON::XS or the XML::Dumper modules pull in, but to me, it looks like both are very lightweight and single modules without further dependencies. That would be a requirement for any suggested replacement as well, needless to say.

Looking for example at the Debian package, there are no further dependencies for the Cpanel::JSON::XS module, in fact, the only reason it has the Cpanel prefix is because it's sponsored by cpanel.

https://metacpan.org/pod/Cpanel::JSON::XS

It's worth reading that a bit, to get a sense of what that module actually is. I also tend to somewhat respect Perl Maven's views, since I've used his online stuff a lot, and Cpanel::JSON::XS was the one he picked to demonstrate json encoding from all the ones he listed (and given it was basically perfect out of the box, that is, the ever so rare condition of "it just worked", would make a replacement have to be demonstrated as radically better in some way in order to justify spending dev time on it).

So tentatively, and because I'm really trying to get this stuff finished up (I have real work waiting on this process), I think I'll only change things at this point if there is a real need to do so, and if the solution can be verified to be better in a significant way. To me, pulling in an entire toolkit to get two modules would not qualify for that requirement I believe. Since most users will be installing modules from their package manager, the modules should be totally standalone.

I may however extend slightly the support, in the interest of very old systems that may not have access to Cpanel::JSON::XS, and make an optional test for just plain JSON::XS, which I believe will work in a similar way. I'll test that maybe today. I don't know the release dates of these modules initially.

However, with that said, I don't like the output of XML::Dumper, and welcome simple light solutions that might produce better output, as good as the essentially flawless json version. But that may require looping and actual processing of the data, which I don't want to do unless a real demonstrated interest in xml export exists.

h2-1 · 03-18-2018, 05:32 PM

I'm working on some other bugs right now, but 0435 will have support for using either JSON::XS or Cpanel::JSON::XS. This should cover most users in most situations, and also allow for very old systems like servers etc to still be able to use the json export function. I've updated --recommends to indicate this option.

Another core requirement for pinxi was that it work on stuff running Perl 5.08 or newer, ie, very old servers or vms that are still running, but which of course cannot upgrade their packages anymore. But could, for example, install something from CPAN directly, for example.

mralk3 · 03-18-2018, 06:40 PM

Keep in mind that Slackware 14.2 runs perl 5.22.2 and (as of today) Slackware-current has Perl 5.26.1. A stock Slackware installation of any sort does not ship with any JSON perl modules. That leaves us Slackware users with the following from SlackBuilds.org: slackbuilds.org search=perl-JSON&sv=14.2. Both look reasonably up to date.

h2-1 · 03-18-2018, 07:44 PM

One of the, if not THE core requirement when I selected the language that inxi would be rewritten in was that the language be what I consider 'adult', that is, not breaking their language features all the time. I've been immensely pleased testing pinxi on ancient systems, it works, all I had to do was not use a few new language features. I have to really give Perl 5.x devs credit, they know how to keep a language reliable and stable. So I develop it on 5.026, and have tested it all along on 5.008, 5.010, 5.012, and whatever variants are on some servers I use for testing. Also on old vm installs. Perl really shines, and has far exceeded my expectations for not breaking their language over time. As long as I am aware of which language features were introduced after 5.008, and avoid them, which has not been hard to do at all, there's been no issues at all. I've documented all these things on the pinxi github inxi-perl branch by the way, and those docs will be moved to master once pinxi moves to inxi.

Note that I just added in JSON::XS as a fallback option, since it's easy to implement too, it's the same syntax exactly. perl-JSON-XS is as you note packaged, so there's no issue, pinxi will test for CPAN::JSON::XS first, then JSON::XS, but it might be worth thinking about packaging the cpanel variant, the reason it was forked was that the maintainers of JSON::XS were not responding to issue reports, and they had some real bugs. As a maintainer / developer myself, I know exactly what that means when it comes to the long term utility of a project. In fact, inxi itself was forked in the very beginning due to the refusal of the previous program's maintainers to accept a trivial patch. So I know exactly what it means when programmers start ignoring issue reports...

However, I don't believe these issues would impact simple stuff like pinxi export to json.

I'll probably add in slackware package names to the built in --recommends tool if I have time to do it, though it would be nice if someone else could provide the package names for slackbuilds so I don't have to look them all up.

mralk3 · 03-18-2018, 08:33 PM

Quote:

Originally Posted by h2-1

I'll probably add in slackware package names to the built in --recommends tool if I have time to do it, though it would be nice if someone else could provide the package names for slackbuilds so I don't have to look them all up.

The dependencies for perl-JSON-XS according to SlackBuilds.org are (must be installed starting with #1 and ending with #4:

I am not the maintainer for any of those, so if something looks outdated, you can contact the maintainer listed on each page by email.

h2-1 · 03-18-2018, 09:02 PM

Oh, I'm not spending time on per distro bugs in packages, all pinxi/inxi does is show recommended package names for a long set of packages, which can be seen if you run --recommends. The only thing requird to add a new package manager to that list is a list of package names, which I fill out currently for apt, rpm, and pacman, by googling the application name plus the package manager name, not particularly scientific, just mundane rote stuff. It's not very interesting to do it, but I wouldn't mind adding some more package managers to the supported ones pinxi already has, since that's now easy to do in perl pinxi. not a big deal, doesn't help me personally, but can help users of the various package managers, and maintainers, so they can quickly look over the recommends to see what's needed.

When you run --recommends in slackware, you won't see missing package names listed because there's no support internally for slackpkg in recommends section, if you run that in say, arch, debian, ubuntu, or fedora, you will see those install names listed. Inxi would just spit them all out no matter what, it wasn't very 'smart' about that.

zakame · 03-19-2018, 12:34 AM

Quote:

Originally Posted by h2-1

zakame, my initial look into the mojo toolkit appears negative, for example, I don't see an apt package for just Mojo::JSON module, only the full collection of mojo tools, which is serious overkill to get a single module installed. Both of the modules I picked do not I believe require further modules, but I'll confirm that. One of the core requirements I have for inxi/pinxi is to keep recommends and dependencies to an absolute barebones minimum.

I'll test on a few systems with barebones Perl installations, to see what either the Cpanel::JSON::XS or the XML::Dumper modules pull in, but to me, it looks like both are very lightweight and single modules without further dependencies. That would be a requirement for any suggested replacement as well, needless to say.

Yeah, Mojo is usually packaged as an all-in-one toolkit for most distros; whether that is overkill seems a matter of taste to me.

You could also look into Tiny modules like JSON::Tiny as well (that one cribs from Mojo::JSON, and probably even smaller enough that you can just inline or adapt the parts you use from it to pinxi too, since it is just pure perl, compared to XS solutions requiring a compiler,) and XML::Tiny (also small enough to be inlined.)

h2-1 · 03-19-2018, 01:14 AM

I'll take a look at both of those, thanks. Basically the output has to be perfect as it is with the json::xs stuff for a change to happen. the xml::tiny is more likely because I don't like XML::Dumper output. Mojo would be out of the question since the point is to avoid such large dependencies, that's why pinxi was written to work with only core modules for example, except for extra features like json export that very few users would use, and those who do, can easily install the module and go on their way.

I'll take a look at the source of those too, it would be nice to get rid of dependencies, but only if they are really reliable, since it's likely json output would be used by other software, so reliability and robustness would be more important than size etc.