đź›  Include inxi in the base install of Fedora moving forward

The Water Cooler
1

Well, I know a Change request would have to be created and other things I am not aware of, So I would like to guage some Community Interest in asking that a certain package inxi be included in the Fedora install by default.

Screenfetch and other tools like serve the community no purpose for identifying hardware better than inxi and it’s the Choice tool for this type of discovery on the forums.

Here is some more information on inxi :

Name         : inxi
Version      : 3.3.34
Release      : 1.fc40
Architecture : noarch
Size         : 2.1 M
Source       : inxi-3.3.34-1.fc40.src.rpm
Repository   : @System
From repo    : updates
Summary      : A full featured system information script
URL          : https://smxi.org/docs/inxi.htm
License      : GPL-3.0-or-later
Description  : Inxi offers a wide range of built-in options, as well as a good number of extra
             : features which require having the script recommends installed on the system.
3 Likes
2

Well, this is less a question for Fedora in general but for the very teams that maintain Workstation, Server, KDE Spin, etc.

They have to be careful what they include, as we have a lot of stuff in our repos but not everything is as well maintained as we want it to be, and the requirements for packages that are shipped by default with the editions are effectively higher than for “any package” in the repo. The major editions select carefully what they include, and usually explicitly ensure its maintenance and proper embedding in the very edition (often a major difference between the official editions compared to, e.g., informal spins - except KDE spin which effectively widely equals a WG but is considered SIG for other reasons).

So including inxi in any edition might bring the burden to explicitly ensure its maintenance and proper embedding throughout evolvement of the very edition.

Problem here: inxi needs a lot of perl stuff that needs to be installed with it, which increases the burden of the very teams if they would include it by default. Afaik, perl packages ain’t the favorites of many people here, and intentionally avoided on Fedora, and adding them by default might cause resistance, although this is only a guess, I cannot talk for these teams/devel people. In any way, we should be careful to assume the implications of having all that perl stuff installed by default.

Personally, I would have not really a problem with it, but someone would have to ensure that all these packages are properly maintained and well tested and embedded with all their configs and so on in the very edition. I assume this will not happen since there are sufficient alternatives available: I never used inxi much, so feel free to correct me, but if I have it correctly in mind, inxi does only accumulate data that is available elsewhere anyway.

So my expectation is that the return on investment is a disadvantageous one.

Supplement: With maintenance, I do not only mean here within Fedora, but also upstream (including collaboration & integration with the very people/teams).

2 Likes
3

We do have fpaste that does the basics and has no deps. It’s been around for ages, and includes functionality to send the info to the fedora pastebin so it’s also useful on headless installs etc.

We (the fedora community) maintain both the fpaste cli and our pastebin)

2 Likes
4

Well, I’ll have to look into it’s use. I did see you use it not too long ago and I bookmarked that Post.

Since I have been back on the forums inxi has been what was more widely used and it is comprehensive. so i went with it as well. I will give fpaste a deeper look. Any tool we can use to provide help for the Users like these is very welcome so I’m glad to see it.

@ankursinha I do have some thing else to discuss about the Quick Docs, and you might be the person to help ! :fedora: :raised_hands:t5:

1 Like
5

Sure, i no longer have commit access to the quuck docs repos, but can always help with PRs etc.

6

So as to not derail this thread, i will Message you my information, questions !

Thanks

1 Like
7

While pretty comprehensive, its output might be too long to be used in the forums.

Its syntax for troubleshooting would be fpaste --sysinfo --printonly ? The idea being for the user to paste the output directly into the post and not uploading to Pastebin.

1 Like
8

Good point ! :100:

1 Like
9

I think Ankur just mentioned an example for comprehensive information. There are many tools for many types of cases. If I just need kernel, release, builds and arch, I just ask for uname -r. A lot of specific information can be cat from /proc/. The point is imho, there are many tools, and so far, I think I never needed to ask users to install something in order to get the information I needed to help. So the question links back to the return on investment (while here the investment is adding inxi and its dependencies to what needs to be integrated and maintained in our editions).

Btw, we also have the possibility to create code blocks in discourse anyway. If they are too big, they will contain the possibility to scroll within the box. That’s comprehensible imho. Even with comprehensive outputs, we can use grep to focus on what we need. External links don’t hurt as well. Personally, I would prefer these possibilities over installing more by default, at least if it adds a lot of new packages.

1 Like
10

Lets determine what is missing, what the benefit of using inxi would be here.

The fpaste syntax to just get infos is completely easy but likely easier than inxi

11

From Ask Fedora to The Water Cooler

12

Added tech-talk and removed f40, workstation-wg

13

I hope it is ok that I moved this to tech-talk / watercooler. It’s no longer ask-fedora or so.

Because it is not yet a change proposal or so but focusing on the general eligibility of inxi rather than how/if to get it into our editions and solve the perl/maintenance issues, I tend to assume it is not yet Project Discussion, but feel free to change that and put it to Project Discussion if you prefer that one.

14

Obviously, code blocks is the way to go for such outputs. Initially I just thought it would still be less legible, but I was wrong. I made a test and scrolling within the block is acceptable.

I see a tendency of those helping out in the forums to ask for direct input in the post/thread and no external links, and I can understand why. Thread navigation is easier this way, and efficiency is probably higher, as opposed to external links (which is welcome, given the obviously limited time resources of those providing help). Being able to find results from within these outputs when searching in the forums is an added bonus.

So long live code blocks :crown: .

2 Likes
15

inxi tends to be the weapon of choice on Manjaro’s forums, though I haven’t seen it as widely used elsewhere. It’s attractive because it provides a lot of useful information (but condensed). I find the command line options somewhat impenetrable, though.

Here’s why inxi is good:

  1. Privacy options. You can blank out sensitive system information that other users don’t need in order to help you (like MAC addresses, for example).
  2. You only need to use inxi and no other tools to get useful output. No need to combine it with uname, lspci and whatever else.

Here’s some more information that would be useful:

  1. On Silverblue systems, rpm-ostree status.
  2. flatpak list. It sometimes provides critical information in solving the issue, as seen here: 'GDK_IS_MONITOR (monitor)' failed · Issue #140 · flathub/io.github.celluloid_player.Celluloid · GitHub

There’s a lot of value in having a single tool for users to use and become familiar with instead of a lot of smaller tools that are very good at their jobs. I know it’s not the UNIX way and all, but we’re on Linux here :slight_smile:

If fpaste prompted me whether I wanted to upload my system information to a pastebin, I think that would be a huge improvement. I don’t think uploading should be the default behavior if fpaste is to be a system diagnostic tool.

2 Likes
16

Apparently, we (and I mean myself too) are missing out the initial main purpose of fpaste. But this is a good opportunity to look deeper into it. Its --help usage says:

Send text file(s), stdin, or clipboard to the Fedora community pastebin at https://paste.centos.org and return the URL

I guess it comes handy when diagnosing (remotely accessed) systems via CLI. You just write down the generated 8-letter code and continue your work on your local system’s browser.

Also, by default, the generated paste file gets deleted in 24 hours. Sorry, it explodes :bomb: . See test paste here. So no biggie if one dind’t use the --printonly or --confirm options.

1 Like
17

Another :100: !

:100:

I don’t think the Category actually matters in this context. It was meant to spur the conversation and also share tooling other might know of.

It’s a lot better than me spending a day working on a POSIX script to achieve the same thing.

Being support on the forum, does require prompt and efficiency. The tooling is the fun part, as we get to understand more how to produce useful logs and teach the user the same. So not only is it Help and Community, it’s a learning experience.

2 Likes
18

One could argue that from the technical side of providing a smooth operating system experience it is the opposite:

inxi = 39 packages to take care of (and some of them might need careful considerations, and need to involve communities/teams that are not yet well intertwined with Fedora)

uname, lspci, and other packages that can get related output = let’s say it is maybe 10-15? Mostly from us or teams that are intertwined with Fedora anyway since its mostly generic tools that are designed to need not much more than the kernel and its immediate dependencies itself.

Beyond, Fedora is strongly intertwined with Python (both from a technical side but also with the community), which makes python stuff comparable easy to include and maintain. What we deploy usually as “tools for the everyday” fits on of the two categories and thus does spare a lot of time and efforts, and limits “room for issues” and complexities.

Just an alternative point of view :wink:

2 Likes
19

Great discussion so far. :clap:t5:

Just wanted to chime in and note some things:

There goes my Lua scripts ! :laughing:

But I am VERY comfortable with Python and would not be opposed to starting a project in the future to have some tooling for certain types of technical support inquiries.

1 Like
20

Paranoid users still can send the inxi to fpaste.

1 Like