As bug reports go, this one has about as many things wrong as you can possibly
get in a short statement.
Note that there is constant churn in distro ID methods, unfortunately, a situation that does not
look like it will ever stabilize, so these methods, while quite reliable, do have to be revisited
now and then. inxi supports them all, or tries to.
Normally I don't accept any issues on older inxi releases that are not current stable branch, but in
this case, the distro id logic hasn't changed in a long time so nothing would make it not work in
the debian pool version that isn't the same in the current master branch version.
Let's start at the most obscure.
1. kfreebsd handler.
Line 824 of current release (2.2.35)
BSD_TYPE explicitly set. In fact, inxi is probably one of the very few system information programs
that actually pays complete attention to the reality of kfreebsd. Kfreebsd was actually initially
tested during the bsd development phase of inxi bsd support, which would make me one of the few
people on the planet to actually have tested/run kfreebsd. Note that I no longer spend time on any
bsd issues for inxi because it's too time consuming, so if users of bsds of any type have patches
for inxi on their bsd flavor of choice, then: https://github.com/smxi/inxi is where to file those
patch/issue reports. I'm happy to improve inxi bsd support, always, but only with complete, tested
patches.
get_distro_data is where you'd be looking for logic errors, a logic error manifesting when you run
inxi on the platform of choice and it reports the wrong distro/os type.
So a bug report that says inxi is wrong that does not even bother to test if inxi is wrong... well,
that's an invalid bug report.
Note that things change, and as noted, I don't do constant checks of the bsd handlers, it takes too
much time.
So the alleged kfreebsd issue isn't an issue until verified by someone who has actually tested inxi
on kfreebsd. I've lost my vm kfreebsd login info so I can't test it without reinstalling the vm, and
since the bug reporter didn't bother doing checking if there even is an issue, there is no issue to
debug. Note that all BSDs do not give much release data, so inxi gives what they give.
So if there is an bug in inxi kfreebsd handling, create a bug report on it, but not one based on
what you believe may happen, it has to be based on what IS happening, including output that shows it
happening.
All BSD type detection in inxi, including kfreebsd, default to using uname -sr for their distro id.
In other words, kfreebsd never even gets to the point of testing /etc/issue or /etc/debian_version,
it's already exited the logic.
2. Now let's move on to the: Distro: /etc/ corrupted, use -% to override
How does this one happen?
It's useful to read the code, but I'll make it easy.
The FIRST thing inxi checks is /etc/debian_version based on the glob of /etc:
cd /etc
a_distro_glob=(*[-_]{release,version})
That gives us:
cat /etc/debian_version | wc -c
12
(stretch/sid)
So it's not using that file information.
A possible thing that could be happening is that there is another file in /etc that matches the
globbing pattern, ie, it's /etc/*_-version|release
Worth checking, if it exists, I'll blacklist that file name in inxi, but it would be literally the
first such in all the years I've done inxi to appear.
the only time /etc/issue is used is if ALL the distro id tests have failed, including lsb-release,
os-release, and anything else. Because I develop on debian, inxi has more robust testing for debian
than anything else. But even there, inxi is going to first test for lsb / os release to confirm that
no other distro id has been found. /etc/issue is the absolute last test attempted, it means all
other tests have failed to come up with anything. And the only time /etc/issue would have triggered
the corrupted error would be if its contents were > 80 characters long. So the /etc/issue thing is
wrong, obviously.
Which now gets us to the very end, the actual issue the person is experiencing.
What triggers the issue of corrupted data? It's if the specific distro id data was > 80 characters,
whichever file it came from, makes no difference.
So to know what triggered this, we'd need to know which ID file was actually
used.
echo -n 'Debian GNU/Linux stretch/sid \n \l' | wc -c
34
So the current stretch /etc/issue is 34 characters. The default debian /etc/issue did not cause this
issue. If the user modified /etc/issue, and if no other distro id file was found, and if they
entered a short essay in the contents of /etc/issue, then yes, you'd see that corrupted error. Then
you'd start inxi with what it says: inxi -b -% and it would show you what was not printed.
I'd need to see the full debugger output to see what did cause it.
inxi considers that to be corrupted when > 80 characters first because it's unlikely any real distro
info is going to be that long, second because it would break the output in a shell. Now people can
create whatever they want in the distro version file that is accessed, like: "my personal spin of a
derived debian based distribution that I like to call wilma version 27.0.2" but inxi isn't going to
print it if it's > 80 characters, since it's obvious the data was corrupted and not usable.
If any of these issues turn out to be real, I suggest the bug reporter follow it up on github, but
don't report issues that haven't been confirmed and validated by you.
Since the poster didn't post what inxi -% -S
shows, ie, what inxi suggested he do to see what's going on, we would have to guess what the file
was. That's of interest to me
So my guess is is that there is a non distro release/version file in the users /etc that is being
parsed, and that appears BEFORE debian_version in the loop that checks these files.
Issues like this are best done on inxi github issue tracker, not on the debian
maintainers bug page.
Sorry for the tone, but when someone reports as an issue something they haven't even bothered to
check, my sympathy falls close to zero.
