inxi/pinxi + --recommends and Slackware package names, help complete list

h2-1 · 05-03-2023, 07:06 PM

I did a test with sboui, and I think this is drifting outside of the repo feature program scope, there's no logical way to put key: value pair data that is not related to the repo url/branch in the current inxi repo tool.

This is running live in pinxi 3.3.26-42 but I suspect at least sboui doesn't qualify as a repo type thing, maybe right on the edge, a gray area, but anything more is definitely not a repo type.

I was actually experimenting with switching the repo reports to standard internal inxi key: value pairs, which would then trip all the line length handlers and wrappers, but I didn't love the initial test results, so I rolled that back. But that test would have supported something like:

pm: built-in branch: current repo: git://git.slackbuilds.org/slackbuilds.git

but the current simple line by line printer doesn't, and there's no real way to cram that data in there in any way that's consistent with the other repo reports.

These are also relatively speaking taking too many lines of code per type, the repo tool is actually intended to really do mainly file based repos, so there's an internal tool to grab that match, automatically. The only ones that require custom handling are ones that place repos in blocks for processing, like slpkg. But I think these two last ones are kind of pushing against what repo tool is actually meant for, it's not meant to be granular per line, though as noted, I did test that a day or two ago, and it had I thought mixed results, some nice, like the lines wrapping, others less nice, like the lines getting longer due to the keys: in the line, and that the secondary indent was lost since that's not supported yet in inxi, since that would then require a 3 level indent logic, which is hard to do safely and well.

But that method would allow for key: value pairs, and remove the use of the '~' separator, which is really just a way to stick in various values along with the repo url.

There's a kind of oddity with these last two as well, they don't seem completely thought out re the configs, like, if the config file is /etc/sboui/sboui-backend.conf, why isn't the value for which repo it is in there too?

I tried this a few ways, but basically the pm doesn't make any sense logically unless there's a key attached to it, like pm: built-in repo: ...

For now, I'm just going to have it read /etc/sboui/sboui-backend.conf and call it good.

Note that for ponce, it replaces whatever value it had for BRANCH with 'current', which I believe if I understand it right is the correct designation based on how sbopkg does it.

For example, while it could, inxi doesn't show apt, rpm, pacman, etc, configurations or anything, it just shows the active repos running.

I did save the code for making some of the repo output into key value pairs, and I may revisit that, since it's actually the last bit of inxi that isn't purely key: value pair based data, for repos, the repo lines are array values, one at a time, that's why they show as basic strings, it just stores the array per file found, and that's it, then prints that array, and numbers the lines to make it readable.

My feeling is that to make these things key: values so I could add more flexible data per repo type, I'd have to also redo the core printer to handle 3 indentation levels, up from 2, and that's a much harder task than it sounds, 2 was already quite difficult to get working. I can see doing this in the future, since that would let me get rid of that last legacy bit of data output, and to simplify the output handler so it doesn't have to test for array or hash references per 'line', though I'd probably leave in the array handler anyway since it might come in handy some day.

Also, to me, sbopkg and sboui barely, just barely, qualify as package manager tools with repos, they really aren't, what inxi is now printing out is just their configuration settings, not really the repos at all in the sense of normal repos.

For example, I wouldn't add this type of support for any Arch Linux AUR tools, there's way too many of them, and I don't want to get that granular, but this is a good way for me to learn about Slackware and the variations so it has some utility for me.

However, sbotools appears to be dead, so I think you can skip that one, unless it shows signs of life, which might happen, Zenwalk suddenly sprang into existence after what seemed an eternity.

I'd say sboui really shouldn't be included because a front end for another package manager doesn't qualify as a repo type, except that it has the built-in type, which suggests it actually has some type of internal package manager, unless it's using something like slpkg internally, in which case I'd say sboui should be removed, because that's not the purpose of the repo things, that would be like including syntaptic for apt or whatever.

In other words, inxi -r should not show any data from specific repo tools, only from the repo data itself. However, slackware is an odd special case because it doesn't have a package manager per se like most distros have, which makes it more of a gray area per package manager tool. But I'd say it's important to really ask, is this an actual real full package manager, or just a front end for other package managers in the ecosystem? If it's the latter, those should be removed imo.

chrisretusn · 05-03-2023, 08:51 PM

Quote:

Originally Posted by h2-1

chrisretusn, sbotools looks dead or dormant, nobody on their listed IRC channel, not even a bot, and not on libera.chat either, where most freenode users migrated.

Last commit I think was 2019, or 2017.

Not sure if this one is worth doing, unless someone can point to signs of life.

Yes I am aware of this. I created a package for it yesterday. There are folks still using it. post post post

h2-1 · 05-03-2023, 11:21 PM

Those links were useful, thanks. Seems like most of the ones people mention most are covered now. The sbotools isn't really a program by the looks of it that can be detected, it's a set of perl scripts that I assume make up the tools, but nothing that in particular makes sense for inxi to try to detect. The tools feature just matches the program name, nothing fancy, so it has no ability to show the 'owner' of a program or set of programs, it's just what is found present in the system.

But it seems from reading those threads that most of the tools people mention are now somewhat handled by inxi/pinxi, but given there are basically just too many to try to handle all, and that most aren't really standard type repo files or configs, I don't know how useful it is to try to cover them all.

It's too bad some of these projects don't get together and pool their efforts, but I know how it is, you want to do things the way you want to do them, I'm the same, so I understand it.

I know for AUR, I basically just collected a list of the main AUR tools, and just show them in the package manager report item, but I think they all use the same repo files, not sure, never really looked into them.

I'm glad to see that sbopkg seemed to be mentioned frequently so that was good to see since it's now crudely added to pinxi, same for slpkg.

I'm kind of shuffling between non inxi stuff, finalizing the upgraded USB feature (I think I finally made my mind up in latest version about where the data goes in each item to be consistent, and I think it was the right choice, because when I looked at inxi output, I thought it was broken, which usually means the choice was ok for the change), and this Slackware repo stuff, which has been extremely educational, so I consider that time fairly well spent overall, though it's a lot of code/logic for these Slackware package managers. Note that I also added netpkg support, from Zenwalk.

In a sense, it would be nice if there was one or max two repo formats, that all the package managers could share, but Slackware is different in this regard so this kind of just highlights that difference I think.

Maybe since there are so many tools, figuring out if any more should show in the packages report as important/useful information would be useful. In other words, tools where you'd consider it valuable to know at a glance if an install had that tool.

There's a lot of changes building up in pinxi, but it took a while to settle on the USB final display options, which I think I did today finally, so I didn't want to rush it, but it's a lot of changes now so should probably be looking for a new release fairly soon, I've been planning to do it almost every day but more interesting stuff keeps coming up.

I like the original thread starter, --recommends for Slackware, which I guess is what started me down the slackware package manager rabbit hole, heh, that actually closed a long standing promise I'd made someone from another distro with another package manager that if I was going to add one, it would be slackware, so that's now finally done. And that will be the last default --recommends packages pm I ever add to default inxi I think, 4 is enough, and covers the vast majority of Linux users. There's docs for maintainers explaining how to add their package manager if it's not covered, but nobody has ever done it as far as I know, but it's quite easy, the docs show how to do it.

chrisretusn · 05-04-2023, 10:29 AM

Sorry about being off topic, I guess the "packages" in the title and @rizitis post threw me off.

Regarding sboui. If you decide to let sboui stay. How it's shown in 3.3.26-44 is fine. In my testing, the repo_dir setting for the allowed package_manager has to point the same repo/branch that is set in sboui-backend.conf. Example, if sboui-backend.conf is set for SBo/15.0 and sboui.conf has package_manager= "sbopkg", then repo_dir = "/var/lib/sbopkg/SBo/15.0". So pinxi could be useful to see if the package managers used with sboui are the same.

This shows that all of the package managers I tested are aligned with sboui. (suggestions) ponce is current.

Code:

  Active sbopkg repo: /etc/sbopkg/sbopkg.conf
    1: SBo-git ~ current
      (current ~ SBo-git)
  Active sboui repo: /etc/sboui/sboui-backend.conf
    1: current ~ https://github.com/Ponce/slackbuilds.git
  Active slpkg repos in: /etc/slpkg/repositories.toml
    1: ponce ~ https://cgit.ponce.cc/slackbuilds/plain/
      (current ~ https://cgit.ponce.cc/slackbuilds/plain/

Same with branch 15.0

Code:

  Active sbopkg repo: /etc/sbopkg/sbopkg.conf
    1: SBo ~ 15.0
      (15.0 ~ SBo) 
  Active sboui repo: /etc/sboui/sboui-backend.conf
    1: 15.0 ~ git://git.slackbuilds.org/slackbuilds.git
  Active slpkg repos in: /etc/slpkg/repositories.toml
    1: sbo ~ https://slackbuilds.org/slackbuilds/15.0/
      (15.0 ~ https://slackbuilds.org/slackbuilds/15.0/)

SlackBuild.org or SBo would the use the same URL and the are presently 11 branches available in SBo (15.0, 14.2, 14.0, 14.1, 13.37, 13.1, 13.0, 12.2, 12.1, 12.0, 11.0). The "ponce" SBo repo is a fork SlackBuild.org for -current.

Quote:

The sbotools isn't really a program by the looks of it that can be detected

/etc/sbotools/sbotools.conf. It's created by sboconfig by setting a value. You can view the default using 'sboconfig -l'

h2-1 · 05-04-2023, 01:17 PM

This is the current logic in the slackware repos that aren't processed to show just the url string:

* sbopkg: $name ~ $branch [no repo]

* sboui: [no name] $branch ~ $repo [with the transformation to make branch = current if ponce in url, I'm also guessing branch could be empty in that case, so inxi makes empty branch into current as well]

* slackpkg+: $name [no branch] ~ $repo [uses a matching logic to match the name in the MIRRORPLUS variable to the name in the active repos in REPOPLUS list, which is awkward but works].

* slpkg: $name [no branch] ~ $repo [repo is synthesized by recombining the 1-3 components of the repo array variable value, one element of which can, but does not necessarily, contain the repo branch]

This pattern suggests the rule:

[name][ ~ ][branch][ ~ ][repo url] where 2 of these occur.

However, the norm here is name + [branch or repo, with the exception of sboui]. As an aside, I think in all the repo types that uses this type of synthetic line constructor, it's always name ~ repo url

slpkg does not contain any reliable way to determine a repo branch, thus, that transformation would be largely a fiction, since the config does not contain a repo_branch=xxx value. I don't view it as inxi's job with repos to make up or try to create data, it should report what it found, with a simple transformation for ponce being reliable, but outside of that, far too finicky and highly and almost certainly prone to long term failure. I shy away from trying to guess stuff like 'if there are greater than 1 "..." blocks in the [], then the second is the branch, because I don't actually believe that's what the logic is doing, it's just a URL constructor, with the base URL then the specific extra stuff to be appended on one by one to the base URL. My experience is this logic almost always fails/breaks long term.

I would suggest that if this type of consistency is desired, it should be something done on the package manager end, if they wanted to do that, and inxi should just report what it found.

To my eyes, of the above, only slpkg offers a standard key:value repo package manager repo listing format, with the full access url as the mirror value, on/off switches per repo type, etc. Also very predictable when reading the configuration, if it's active, it's on, if not, it's not, except for SBo, which is off if ponce is active. And it's the only one that is an actual repo file, not a general configuration file.

netpkg, slackpkg use the simple 1 line repo listing, inxi already has a tool to generate those, so those require only 1 line of code, plus the values for each pm type, and the check lines.

I don't personally see it worth spending too much more time on sbopkg and sboui because neither really offer a standard repo configuration file syntax, and seem to operate more as custom sbo handlers than full fledged package managers. To me the probable value is simply showing their files exist, and as far as inxi can determine, have those values it finds, but I don't really want to go much further into these woods, it's already veering significantly away from what repos are really supposed to show, but I do see the value of supporting the main ones that are most common.

I do wonder if maybe just a single repo type item: SlackBuiids.org tools: or something like that might not work better for these, with key: value pairs for the data they have per line, food for thought longer term, at some point it would probably not be the worst idea to show key: value pair data from configuration key:value pairs in config files as what they are called, and not worry about it any more, beyond simple transformations. Maybe I'll poke around with that for a future inxi release, I tried it out this time as noted, and found the results mixed, some good, some bad. Repos are a very old inxi item, made originally to be very simple, and has grown over years to handle most of the common repo config or command outputs in BSD and Linux. But I feel these multiple configuration file based items are probably not ideally suited to current inxi repos, they can be sort of crammed in, but they strain the logic and output consistency.

chrisretusn · 05-05-2023, 12:07 PM

Excellent info. I will throw some ideas, observations in the the hat.

Quote:

Originally Posted by h2-1

This is the current logic in the slackware repos that aren't processed to show just the url string:

* sbopkg: $name ~ $branch [no repo]
Default $repo for all branches except current would be rsync://slackbuilds.org/slackbuilds/$branch/, this is hinted in /etc/sbopkg/repos.d/40-repos.conf. This can be redefined, I created a 30-repos-git.conf using git vice rsync. One cannot expect pinxi to figure that one out.
Default $repo for current is https://github.com/Ponce/slackbuilds.git@$branch found in 60-repos.conf
$name ~ $repo would work here. If it's not to much work to work that out.

* sboui: [no name] $branch ~ $repo [with the transformation to make branch = current if ponce in url, I'm also guessing branch could be empty in that case, so inxi makes empty branch into current as well]
$name could be SBo for all even Ponce, after all it is a fork of SBo. Yes $branch could be empty since Ponce is in the $repo.

* slackpkg+: $name [no branch] ~ $repo [uses a matching logic to match the name in the MIRRORPLUS variable to the name in the active repos in REPOPLUS list, which is awkward but works].
Yes it does, in most cases the $branch is in $repo.

* slpkg: $name [no branch] ~ $repo [repo is synthesized by recombining the 1-3 components of the repo array variable value, one element of which can, but does not necessarily, contain the repo branch]
More below.

Quote:

This pattern suggests the rule:

[name][ ~ ][branch][ ~ ][repo url] where 2 of these occur.

However, the norm here is name + [branch or repo, with the exception of sboui]. As an aside, I think in all the repo types that uses this type of synthetic line constructor, it's always name ~ repo url

I'm of the mind that all that is needed is $name ~ $repo.

Quote:

slpkg does not contain any reliable way to determine a repo branch, thus, that transformation would be largely a fiction, since the config does not contain a repo_branch=xxx value. I don't view it as inxi's job with repos to make up or try to create data, it should report what it found, with a simple transformation for ponce being reliable, but outside of that, far too finicky and highly and almost certainly prone to long term failure. I shy away from trying to guess stuff like 'if there are greater than 1 "..." blocks in the [], then the second is the branch, because I don't actually believe that's what the logic is doing, it's just a URL constructor, with the base URL then the specific extra stuff to be appended on one by one to the base URL. My experience is this logic almost always fails/breaks long term.

I think with slpkg just stick with $name ~ $repo. I all cases except gnome, the version in is the $repo url.

Quote:

I would suggest that if this type of consistency is desired, it should be something done on the package manager end, if they wanted to do that, and inxi should just report what it found.

It would be nice.

Quote:

To my eyes, of the above, only slpkg offers a standard key:value repo package manager repo listing format, with the full access url as the mirror value, on/off switches per repo type, etc. Also very predictable when reading the configuration, if it's active, it's on, if not, it's not, except for SBo, which is off if ponce is active. And it's the only one that is an actual repo file, not a general configuration file.

Understandable. Interesting note: with sbo and ponce set to true, ponce is used. With both false sbo is used. In a nut shell, if all repos are false, sbo will still be used. This is one uses 'slpkg update', if one never uses that and sticks to 'slpkg update --bin-repo='*'

Quote:

netpkg, slackpkg use the simple 1 line repo listing, inxi already has a tool to generate those, so those require only 1 line of code, plus the values for each pm type, and the check lines.

Yes, both are similar in that you can only have one choice.

Quote:

I don't personally see it worth spending too much more time on sbopkg and sboui because neither really offer a standard repo configuration file syntax, and seem to operate more as custom sbo handlers than full fledged package managers. To me the probable value is simply showing their files exist, and as far as inxi can determine, have those values it finds, but I don't really want to go much further into these woods, it's already veering significantly away from what repos are really supposed to show, but I do see the value of supporting the main ones that are most common.

Yet for Slackware SBo is considered a repo. These package managers that handle SBo download, build, create packages and install them. Once installed, standard package management applies. A bonus is the in some of these SBo managers handle dependencies.

Quote:

I do wonder if maybe just a single repo type item: SlackBuiids.org tools: or something like that might not work better for these, with key: value pairs for the data they have per line, food for thought longer term, at some point it would probably not be the worst idea to show key: value pair data from configuration key:value pairs in config files as what they are called, and not worry about it any more, beyond simple transformations. Maybe I'll poke around with that for a future inxi release, I tried it out this time as noted, and found the results mixed, some good, some bad. Repos are a very old inxi item, made originally to be very simple, and has grown over years to handle most of the common repo config or command outputs in BSD and Linux. But I feel these multiple configuration file based items are probably not ideally suited to current inxi repos, they can be sort of crammed in, but they strain the logic and output consistency.

With Slackware the closest thing we have to all third party packages in one place is SlackBuilds.org and Ponce's fork (SBo). There are no packages on SBo. Package managers that handle SBo must use the resources available to download, build and install a package, this can include dependencies. They must also manage the upgrading and removal of these packages. Slackware does not provide this function for third party packages or as I like to call them non-slack packages. The non SBo package managers (slackpkg+ for exmaple) deal exclusively with a repo of packages. Even slpkg, splits between SBo and packages (slpkg update, slpkg update --bin-repos='*"). Of these there are several package repositories to pick from.

Quote:

Repos are a very old inxi item, made originally to be very simple, and has grown over years to handle most of the common repo config or command outputs in BSD and Linux

My thought on read this was... and then came along Slackware.

In practice, all of these package managers are used in computers of a particular branch. That branch is identified in /etc/slackware-version. For this system it is "Slackware 15.0+", the 15.0+ meaning -current. Now I realize that there are cases where one computer host repos for different versions; however, if one is using a package manager on a computer, it is normally being use for that computer.

I favor $name ~ $ $repo. It just looks right.

Here is my current setup with all the "tools" I been testing:

Code:

~# ./pinxi -ra --vs
pinxi 3.3.26-45 (2023-05-04)
Repos:
  Packages: pm: pkgtool pkgs: 2018 libs: 344
    tools: sbopkg,slackpkg,slpkg pm: rpm pkgs: 0
  Active sbopkg repo: /etc/sbopkg/sbopkg.conf
    1: SBo-git ~ current
  Active sboui repo: /etc/sboui/sboui-backend.conf
    1: current ~ https://github.com/Ponce/slackbuilds.git
  slackpkg mirror in: /etc/slackpkg/mirrors
    1: file://home/slackware/slackware64-current/
  slapt-get repos in: /etc/slapt-get/slapt-getrc
    1: https://slackware.osuosl.org/slackware64-current//:OFFICIAL
    2: https://slackware.osuosl.org/slackware64-current/extra/
    3: https://slackware.osuosl.org/slackware64-current/testing/:PREFERRED
    4: file:///home/non-slack/slackbuilds/:CUSTOM
    5: file:///home/non-slack/alienbob/:CUSTOM
    6: file:///home/non-slack/alienbob_restricted/:CUSTOM
    7: file:///home/non-slack/multilib/current/:CUSTOM
  slackpkg+ repos in: /etc/slackpkg/slackpkgplus.conf
    1: justpkgs ~ dir://home/non-slack/justpkgs/
    2: nonslack ~ file://home/non-slack/slackbuilds/
    3: multilib ~ file://home/non-slack/multilib/current/
    4: restricted ~ file://home/non-slack/alienbob_restricted/
    5: alienbob ~ file://home/non-slack/alienbob/
  Active slpkg repos in: /etc/slpkg/repositories.toml
    1: ponce ~ https://cgit.ponce.cc/slackbuilds/plain/
    2: alien ~ https://slackware.nl/people/alien/sbrepos/current/x86_64/
    3: restricted ~ https://slackware.nl/people/alien/restricted_sbrepos/current/x86_64/
    4: conraid ~ https://slack.conraid.net/repository/slackware64-current/
    5: slackonly ~ https://packages.slackonly.com/pub/packages/current-x86_64/

Now with what I plan to use:

Code:

~# ./pinxi -ra --vs
pinxi 3.3.26-45 (2023-05-04)
Repos:
  Packages: pm: pkgtool pkgs: 2018 libs: 344
    tools: sbopkg,sboui,slackpkg,slapt-get,slpkg pm: rpm pkgs: 0
  Active sbopkg repo: /etc/sbopkg/sbopkg.conf
    1: SBo-git ~ current
  slackpkg mirror in: /etc/slackpkg/mirrors
    1: file://home/slackware/slackware64-current/
  slackpkg+ repos in: /etc/slackpkg/slackpkgplus.conf
    1: justpkgs ~ dir://home/non-slack/justpkgs/
    2: nonslack ~ file://home/non-slack/slackbuilds/
    3: multilib ~ file://home/non-slack/multilib/current/
    4: restricted ~ file://home/non-slack/alienbob_restricted/
    5: alienbob ~ file://home/non-slack/alienbob/
  Active slpkg repos in: /etc/slpkg/repositories.toml
    1: ponce ~ https://cgit.ponce.cc/slackbuilds/plain/
    2: alien ~ https://slackware.nl/people/alien/sbrepos/current/x86_64/
    3: restricted ~ https://slackware.nl/people/alien/restricted_sbrepos/current/x86_64/
    4: conraid ~ https://slack.conraid.net/repository/slackware64-current/
    5: slackonly ~ https://packages.slackonly.com/pub/packages/current-x86_64/

Notes: On above. slpkg ponce has never been updated, so it's not present in /var/lib/slpkg/repositories/. I plan to use this for searches only with --bin-repo. I also plan to use sbopkg for searches on SBo-git (ponce). Slackpkg with Slackpkg+ will continue to be my package manager.

A few other thoughts.

pinxi/inxi -ra "tools: sbopkg,sboui,slackpkg,slapt-get,slpkg pm: rpm pkgs: 0"
While rpm is part of Slackware, it's not really functional for Slackware as a package manager. Thus pktools would be a better choice. I'd could say slackpkg, but it comes in the "ap" application series (as does rpm) while pkgtools is in the "a" base series. So pkgtools wins.

Now for some on topic stuff.
./pinix --recommends, my thoughts on rpm apply here as well.
[I]bt-adapter
pkgtool: bluez bt-adapter is not part of bluez. I couldn't find any packages, probably because it's a git build.

--recommends is a really great thing to have.

In one of the older threads you mentioned Parse::EDID. I installed it, should is this be a --recommends?

rizitis · 05-05-2023, 02:25 PM

@chrisretusn be careful with slackonly for current... its outdated

h2-1 · 05-05-2023, 05:02 PM

Great stuff chrisretusn, appreciate the thoroughness and thought.

Just a few quick answers, I have to think more on some of the other points you raised:

* Parse::EDID was non-maintained and buggy and incomplete, so I ended up forking it, and it's now included inside of inxi, the features it offered were too critical for the monitor report to not have it be a built in. I did submit my upgrade to cpan, but never heard back from them, not a whisper, not a peep, silence. I even maintained the style of my update file I submitted, but now that I have not heard back from them ever I dropped that, and am just fully integrating it into inxi and its style. Has much more functional debuggers now by the way. That was written by I think Mandrake in like 2008, I think for their installer, and never apparently upgraded or updated after that. I am fairly certain that inxi is now the biggest user of that forked module anywhere, probably by several orders of magnitude. You could tell they wrote it to solve a specific thing for themselves, because they didn't finish the job, and left some of the edid data unhandled, inxi completed those items, and fixed the really strange debuggers they used.

* I could have sworn I saw bt-adapter listed in the file list of bluez, I double checked all those, or thought I did, since I just checked it again and it's not listed by slackpkg. Should I make that N/A or just unknown? Any idea? Do you think it's a slackbuild? What should I list do you think?

* Re rpm showing, this was to correct a significant issue in --recommends, before it used a simple first pm found, use, rule, but I realized that that depended literally on the order of discovery. The package managers are not in any way distro connected, it's simply: does this pm exist on the system?

The solution was to make --recommends 100% distro agnostic, if the package manager is found, it shows it as an option. Similar to the package report, that is, that tool has zero to do with the distro running it, inxi doesn't know what distro is running it in packages or repos, it's only looking for the application in PATH, or files, for repo.

This is why package managers with 0 packages detected only show with -I/-r -a. rpm is unfortunately a special case due to some very odd programming that has at times made it incredibly slow to produce a list of installed packages, even with all the optimizing switches used. I think inxi can determine if rpm is not the primary built in pm however, so it shows the report, yes, confirmed, that's what it does, I don't remember the rule that lets it assume not primary.

I'll give the SBo repo handling some thought, thanks.

chrisretusn · 05-05-2023, 11:09 PM

Quote:

Originally Posted by rizitis

@chrisretusn be careful with slackonly for current... its outdated

Yes it is, it's just for look ups. I tossed it in the mix on a whim. I in general do not install packages build by others, I prefer to build my own. That said point made, probably will drop it.

chrisretusn · 05-06-2023, 12:56 AM

Quote:

Originally Posted by h2-1

Great stuff chrisretusn, appreciate the thoroughness and thought.

Regarding rpm. It's an annoyance, rpm is pretty much useless in Slackware. I would never install a rpm package without extracting the content and creating a SlackBuild from that. Of course I'm not the only Slackware user. It would be interesting to know if any Slackers use rpm and how they do it. For Slackware pkgtools in the base package manager. It almost all cases with a small number of exceptions, pkgtools is used in third party package manager tools.

Thanks for the detailed explanation of Parse::EDID, now that you mention it, I think you raised this issue before. I suspected as much since --edid works the same, installed or not. I will remove the package from my repository.

Quote:

* I could have sworn I saw bt-adapter listed in the file list of bluez, I double checked all those, or thought I did, since I just checked it again and it's not listed by slackpkg. Should I make that N/A or just unknown? Any idea? Do you think it's a slackbuild? What should I list do you think?

It not listed in any package repository that I seached, I also used slakfinder. It's not listing in SBo either. At first I thought it was purely a git clone build, I found a release tarball. I could submit this to SBo but since I do not have a bluetooth device for testing, not sure it would be appropriate as a maintainer.

List as no package available or indicate build one.

h2-1 · 05-06-2023, 02:53 PM

bt-adapter now should show as N/A, which leaves it up to the user to decide what to do.

rpm is a pain, agreed, I also have it installed with zero packages, not sure what pulled that one in, but in this case, the job of inxi is to inform, leaving it up to the user to decide to remove the tool or not.

That was an odd little thing that had never really been reliable in --recommends because it could have landed on another pm installed before the real pm, so I decided just dump the decision and show it for everything found, up to the user to know that if it's slackware, they probably don't want to do the rpm thing. I believe rpm is the most commonly installed 3rd party repo tool in non rpm systems, not really sure why anyone would risk the health of their system using such things but they exist. Even Arch has rpm.

I had to check, yes, --edid does do something -Ga doesn't, show EDID advanced data, errors, and warnings. Adds chroma, and full supported modes detected, not just the min/max ones. But edid data is used in the -Gxx > -Ga report too, just not all of it.

chrisretusn · 05-07-2023, 01:58 AM

Thanks, inxi is one heck of an information program.

Quote:

Originally Posted by h2-1

rpm is a pain, agreed, I also have it installed with zero packages, not sure what pulled that one in, but in this case, the job of inxi is to inform, leaving it up to the user to decide to remove the tool or not.

rpm is part of Slackware, it's in the AP Series of packages. Doing the recommended full install of Slackware will install it.

Quote:

That was an odd little thing that had never really been reliable in --recommends because it could have landed on another pm installed before the real pm, so I decided just dump the decision and show it for everything found, up to the user to know that if it's slackware, they probably don't want to do the rpm thing. I believe rpm is the most commonly installed 3rd party repo tool in non rpm systems, not really sure why anyone would risk the health of their system using such things but they exist. Even Arch has rpm.

I understand. Perhaps rpm is needed for something in Slackware, not sure what that would be though. I played around with it a bit. It's semi-functional in that you can query things from an rpm package that's about it. You can even install with it 'rpm -ivh --nodeps', do not try this at home.

Quote:

I had to check, yes, --edid does do something -Ga doesn't, show EDID advanced data, errors, and warnings. Adds chroma, and full supported modes detected, not just the min/max ones. But edid data is used in the -Gxx > -Ga report too, just not all of it.

I removed my perl-Parse-EDID package.

This is my pinxi report now. I'm adding -Gxx just for kicks:

Code:

~# ./pinxi -ra -Gxx --vs
pinxi 3.3.26-48 (2023-05-06)
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 730] vendor: ZOTAC driver: nvidia
    v: 470.182.03 alternate: nvidiafb,nouveau,nvidia_drm non-free:
    series: 470.xx+ status: legacy-active (EOL~2023/24) arch: Kepler
    code: GKxxx process: TSMC 28nm built: 2012-18 pcie: gen: 1 speed: 2.5 GT/s
    lanes: 8 bus-ID: 02:00.0 chip-ID: 10de:1287 class-ID: 0300
  Display: server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1
    compositor: kwin_x11 driver: X: loaded: nvidia gpu: nvidia display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 1366x768 s-dpi: 84 s-size: 413x232mm (16.26x9.13")
    s-diag: 474mm (18.65")
  Monitor-1: DVI-D-0 res: 1366x768 hz: 60 dpi: 85
    size: 410x230mm (16.14x9.06") diag: 470mm (18.51") modes: N/A
  API: OpenGL v: 4.6.0 NVIDIA 470.182.03 renderer: NVIDIA GeForce GT
    730/PCIe/SSE2 direct-render: Yes
Repos:
  Packages: pm: pkgtool pkgs: 2007 libs: 343 tools: sbopkg,slackpkg pm: rpm
    pkgs: 0
  Active sbopkg repo: /etc/sbopkg/sbopkg.conf
    1: SBo-git ~ current
  slackpkg mirror in: /etc/slackpkg/mirrors
    1: file://home/slackware/slackware64-current/
  slackpkg+ repos in: /etc/slackpkg/slackpkgplus.conf
    1: justpkgs ~ dir://home/non-slack/justpkgs/
    2: nonslack ~ file://home/non-slack/slackbuilds/
    3: multilib ~ file://home/non-slack/multilib/current/
    4: restricted ~ file://home/non-slack/alienbob_restricted/
    5: alienbob ~ file://home/non-slack/alienbob/

I removed all of the package tools I added for testing from my system, except for sbopkg for SBo searches.

h2-1 · 05-07-2023, 01:55 PM

Chris, I've changed sboui to use 'Sbo [branch] ~ [repo]'. Other changes will have to wait for the future, the problem of the perfect being the enemy of the good, and my needing to take care of some pressing non inxi stuff, so need to release 3.3.27 today, finalizing docs and last fix, which is interesting.

This handles the issue of free / /proc/meminfo reporting MemTotal as total memory, when it's actually the total MINUS reserved and kernel code, which I had not been aware of. I realized this while documenting internal inxi size/speed handlers, and finally realized RAM actual was not matching Memory total. Also I believe video ram can be subtracted in some cases, definitely for raspberry pi, maybe for standard gpu that doesn't use it's own ram.

Code:

inxi -I
Memory: 31.28 GiB used: 26.29 GiB (84.1%)

pinxi -I
Memory: available: 31.28 GiB used: 26.35 GiB (84.3%)

inxi -m
Memory: RAM: total: 31.28 GiB used: 26.36 GiB (84.3%)

pinxi -m
Memory: System RAM: available: 31.28 GiB used: 26.44 GiB (84.5%)

This is where it can be found in dmesg, but dmesg is not used by inxi because sometimes it requires sudo/root to run (recent debian/ubuntu change), other times it's filled with kernel or device oops, and loses the boot data.

Code:

dmesg 
... [    0.000000] Memory: 32784756K/33435864K available (10252K kernel code, 
1243K rwdata, 3324K rodata, 1584K init, 2280K bss, 651108K reserved, 0K 
cma-reserved)

I've crammed a ton of fixes into this inxi, too many to be safe, so I should release, it's getting hard to keep the various docs, help, man, and code, in sync.

h2-1 · 05-07-2023, 02:50 PM

These changes are now in 3.3.27, just released.

h2-1 · 05-07-2023, 07:53 PM

chrisretusn, just FYI, you aren't getting the advanced data with -Gxx because nvidia-drm.modeset=1 is not set in kernel boot parameters. That creates the /sys directory where all the advanced data lives, including the EDID file that inxi reads. Without the drm directory, you also don't get the ports report, since that lives in the same place.

Another FYI: -a == -a + -xxx so -a overrides -xx. The extra data options apply globally to all switches when used.

Code:

pinxi -Gaz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel alternate: amdgpu arch: TeraScale-2 code: Evergreen
    process: TSMC 32-40nm built: 2009-15 pcie: gen: 1 speed: 2.5 GT/s
    lanes: 16 link-max: gen: 2 speed: 5 GT/s ports: active: DVI-I-1,VGA-1
    empty: HDMI-A-1 bus-ID: 0a:00.0 chip-ID: 1002:68f9 class-ID: 0300
    temp: 57.0 C
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.8
    compositor: xfwm v: 4.18.0 driver: X: loaded: modesetting dri: r600
    gpu: radeon display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 2560x1024 s-dpi: 96 s-size: 677x270mm (26.65x10.63")
    s-diag: 729mm (28.7")
  Monitor-1: DVI-I-1 pos: primary,left model: Samsung SyncMaster
    serial: <filter> built: 2004 res: 1280x1024 hz: 60 dpi: 96 gamma: 1.2
    size: 338x270mm (13.31x10.63") diag: 433mm (17") ratio: 5:4 modes:
    max: 1280x1024 min: 720x400
  Monitor-2: VGA-1 pos: right model: Dell 1908FP serial: <filter>
    built: 2008 res: 1280x1024 hz: 60 dpi: 86 gamma: 1.4
    size: 376x301mm (14.8x11.85") diag: 482mm (19") ratio: 5:4 modes:
    max: 1280x1024 min: 720x400
  API: OpenGL v: 4.5 Mesa 22.3.3 renderer: AMD CEDAR (DRM 2.50.0 /
    5.19.0-16.2-liquorix-amd64 LLVM 15.0.6) direct-render: Ye

I highlighted the parts that are added by that drm modesetting, which is default for things like radeon, nouveau, amdgpu, intel, etc.