Inxi testing

[Member h2]

inxi 3.3.18 is now out, with this slimski support, and a critical bug fix for an error I made in 3.3.17.

[update]You beat me to it, lol. Glad to get slimski added. I know stuff like this doesn’t change that often, but if something like it happens again, do feel free to let me know well in advance so I can add support before release of the item. But it’s not common I realize for core things like this to be forked.

Oh, to handle showing version and a specific item, inxi 3.3.17 introduced –version-short, aka –vs, which lets you do this:

pinxi -Sxxxz --vs
pinxi 3.3.18-01 (2022-06-13)
System:
  Kernel: 5.16.0-11.1-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 11.2.0 Desktop: Xfce v: 4.16.0 tk: Gtk v: 3.24.24 info: xfce4-panel
    wm: xfwm v: 4.16.1 vt: 7 dm: LightDM v: 1.26.0
    Distro: Debian GNU/Linux bookworm/sid

When used with one or more line items, –vs prints the version/date info first, then prints as usual the lines.

• This topic was modified 10 months, 4 weeks ago by h2.
• This topic was modified 10 months, 4 weeks ago by h2.
• This topic was modified 10 months, 3 weeks ago by Brian Masinick.

inxi system information script (install info) :: inxi git

[Moderator caprea]

Helpful

Up

0

::

There’s a problem with the repos

$ inxi -r --vs
inxi 3.3.18-00 (2022-06-13)
Can't use an undefined value as an ARRAY reference at /usr/bin/inxi line 22096.

[Member h2]

Helpful

Up

0

::

damnit, I knew the refactor did not get enough testing, but I’m at the point of basically giving up trying to get testers now, which forces me to release stuff without enough testing.

This is the same issue except different location that inxi 3.3.17 had, unfortunately, all my systems are apt, and none showed this repos issue. Makes it very difficult to catch bugs.

I’ll have a bug fix for this one soon.

that’s with -r, thanks

inxi system information script (install info) :: inxi git

[Member h2]

Helpful

Up

0

::

While this is technically a bug, and was caused by the refactor (using an undefined array reference), in an apt system, that file should never have been unreadable, and thus would never get tripped.

This means that for one of your /etc/apt/sources.list or /etc/apt/sources.list.d/*.list files it has been set as not readable.

I don’t know of anything that would do that, you can figure this out by doing:

ls -l /etc/apt/{sources.list,sources.list.d/*.list}
-rw-r--r-- 1 root root 1431 May 30 15:28 /etc/apt/sources.list
-rw-r--r-- 1 root root  189 Aug  1  2019 /etc/apt/sources.list.d/google-chrome.list
-rw-r--r-- 1 root root  188 Jan 13  2020 /etc/apt/sources.list.d/opera-stable.list
-rw-r--r-- 1 root root  187 Dec 23 16:09 /etc/apt/sources.list.d/vivaldi.list
-rw-r--r-- 1 root root  138 Apr 10  2021 /etc/apt/sources.list.d/vscodium.list

Under no circumstance should a .list file not be world readable, so I’m assuming this is a bug in the creation of the file, and not a standard situation.

I did fix this in pinxi now, since that was caused by the refactor, and should not have tried to use the array reference if the file was not readable, since then it would be undefined. The function itself, repo_builder, always returns an array reference, so the only way to trip this glitch was if your .list file was set to not be world readable.

Having used debian for too many years to be healthy, I consider that a local issue that should be resolved on your system, but I do apologize for that oversight, I expected there to be more because it was a large internal refactor that moved away from a fairly inefficient and simplistic method, but one that would always work, to one that is optimized for performance, but created this failure case.

Problem is it’s not possible to find all the places it might have happened, I thought I’d got the last of them in 3.3.18, but apparently I missed these two lingering ones since technically they should never have tripped on any standard system, but it was an oversight.

I’m curious just for my own sake, what is the result of that ls -l I put above on your specific system?

Creating a simple text file that is not world readable where no security issues exist about that file being world readable strikes me as a mistake, that tripped this little glitch. I recommend just correcting your file permissions, but if anyone else shows up with this issue I’ll do a 3.3.19 just to be on the safe side.

To be clear, one of your apt *.list files is marked as not world readable, which isn’t a thing that should happen in a debian system as far as I know, those aren’t like password files or anything like that.

So on a purely technical level, this is an inxi bug, but on a more general level, I don’t think it’s a glitch that will impact users since the situation never happens as far as I know unless you actually set one of those files to have the wrong permissions.

• This reply was modified 10 months, 3 weeks ago by h2.

inxi system information script (install info) :: inxi git

[Forum Admin anticapitalista]

Helpful

Up

0

::

antiX no longer ships with /etc/apt/sources.list

That triggers the array error message.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Forum Admin anticapitalista]

Helpful

Up

0

::

Request – Under System, show which init is being used. (apologies if it does this already, I cannot see it).

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Moderator caprea]

Helpful

Up

1

::

Like anticapitalista said ,there’s no /etc/apt/sources.list on antiX

$ LANG=C ls -l /etc/apt/{sources.list,sources.list.d/*.list}
ls: cannot access '/etc/apt/sources.list': No such file or directory
-rw-r--r-- 1 root root 724 Jun 15 13:09 /etc/apt/sources.list.d/antix.list
-rw-r--r-- 1 root root  79 May 15 01:56 /etc/apt/sources.list.d/brave-browser-release.list
-rw-r--r-- 1 root root 121 Oct 31  2021 /etc/apt/sources.list.d/bullseye-backports.list
-rw-r--r-- 1 root root 185 Mar  4 10:19 /etc/apt/sources.list.d/debian-stable-updates.list
-rw-r--r-- 1 root root 901 Apr 28 21:23 /etc/apt/sources.list.d/debian.list
-rw-r--r-- 1 root root 185 Jun 10 03:54 /etc/apt/sources.list.d/opera-beta.list
-rw-r--r-- 1 root root 187 Jun 10 03:54 /etc/apt/sources.list.d/opera-stable.list
-rw-r--r-- 1 root root  60 May 27 22:01 /etc/apt/sources.list.d/various.list

Information about the init is there, but under info.

[Member h2]

Helpful

Up

0

::

OH!!!! That explains it. The single factor I had not considered, right, inxi apt repo assumes that file always exists, that explains the readable test.

I guess in that case I’ll do a 3.3.19, how annoying.

This is a scenario I would literally never have imagined, but that’s a sign of my having used debian too long. The resl solution is to not add that file to the loop of tests unless it exists, I see that now.

Discussing with Unit193 whether to do a patch to 3.3.18 in master or to do a 3.3.19, since this is a purely debian only issue, I lean towards patching 3.3.18

• This reply was modified 10 months, 3 weeks ago by h2.

inxi system information script (install info) :: inxi git

[Member h2]

Helpful

Up

0

::

A rush release, 3.3.19 is out now. Thanks for alerting me to this issue, it was also one not in Unit193’s test suite, so nobody noticed it.

I also finally did a full release script, which basically automates the entire release, except for committing it to github, which I use a separate script for.

inxi system information script (install info) :: inxi git

[Moderator caprea]

Helpful

Up

0

::

Now works perfectly again including the repos, many thanks for the very fast fix.

[Forum Admin anticapitalista]

Helpful

Up

0

::

Also, confirm it works correctly.
Sent up to repos

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member h2]

Helpful

Up

1

::

This was a very large internal refactor, many chunks using search and replace because there were so many items to update, and unfortunately, that created these types of bugs, which I’m hoping we don’t see too many more of.

This issue was not local to AntiX as I first thought, or one system, but rather, could hit all ubuntu/debian based systems, which is a lot of operating systems. So I appreciate the heads up. Unit193, the debian packager, had tried to tell me this too, but I had thought he was talking about another bug that had been fixed already, that was a simple misunderstanding.

inxi system information script (install info) :: inxi git

[Moderator Brian Masinick]

Helpful

Up

0

::

I tested today too.
I had 3.3.18 and inxi -r failed.

I manually updated to 3.3.19 and inxi -r worked as expected.

I tried a few other options and the ones I tried worked too, but I didn’t run an exhaustive test of every option; that’s probably an advisable test suite, especially if anything changes.

--
Brian Masinick

[Member h2]

Helpful

Up

0

::

anticapitalista wrote:

Request – Under System, show which init is being used. (apologies if it does this already, I cannot see it).

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit – leaner and meaner.

I wish I had seen this post, sorry, missed it.

inxi is supposed to support runit, there must be some difference, wish we could have gotten this one into 3.3.19.

The test I have, from when I first did the runit, is:

cat /proc/1/comm

that was supposed to have ‘runit’ as content.

It has no fallback tests. Also, no known version method, like runit –version or whatever, emphasis on the ‘known’.

Note that init: requires -Ix or greater. init:.. v: .. runlevel/target: requires -Ixx or greater.

I have very little information on runit, but it should have shown as the init system, I don’t know about the runlevels, I have zero data on that.

Actually, heh, no, it’s not under System -S/–system, it’s under -I/–info. System has the hostname, kernel info, desktop/wm/dm, distro.

-I / Info has the more core system data, like processes running, uptime, ram, init, installed compilers, packages, shell, and inxi/pinxi version. It’s always been like that.

• This reply was modified 10 months, 3 weeks ago by h2.

inxi system information script (install info) :: inxi git

[Moderator Brian Masinick]

Helpful

Up

0

::

Take your time.
We love the features you have and will appreciate it when you have time to properly implement and test the latest updates with runit.

I have a runit implementation on antiX 21 and would be happy to test too.

--
Brian Masinick

[Author]

Posts