Siduction Forum > Scripting & Kernelhacking

[EN] inxi bugs or failures - please report

<< < (15/15)

melmarker:
but it's nice to hear that inxi is still in development even if it will not reach the debianoid world

h2:
mel, you're fairly out of touch, inxi is in debian stable, testing, and sid. Has been for a while. As well as gentoo, arch, mint, ubuntu, opensuse, fedora, redhat, mageia, and so on. Also freebsd and a few other bsd variants, though I don't track that much. Plus many derived distros that may package it to have the latest version available, like solus, antix, desktopBSD, etc. mageia has been particularly quick to update, along with arch since the start of packaged inxi. It's also included in the xubuntu installation cd, since it makes user support much easier. I happened to notice that our ancient forerunner, what started it all here, knoppix (knoppix->kanotix->sidux-...) now ships it with his live cd as well, which I thought was interesting. It was only due to a ridiculous mix up, in fact, that inxi didn't make it into old stable, someone had filed a totally invalid issue report that clogged up the introduction of inxi into that stable, but it entered debian right after that, once the issue was cleared out.


--- Code: ---apt-cache policy inxi
inxi:
  Installed: (none)
  Candidate: 2.3.1-1
  Version table:
     2.3.1-1 500
        500 http://mirrors.kernel.org/debian unstable/main i386 Packages
        200 http://mirrors.kernel.org/debian stretch/main i386 Packages
--- End code ---

debian obviously lags a bit between updates, but it's been a lot better as of late, particularly since both 2.3.1 and 2.3.2-2.3.3 contain 'killer' new features which are highly desirable for system support.

inxi's development basically tracks interesting user issues, and things I want, like the relatively new battery info that 2.3 introduced. Both the uefi/bios detection and the new device detection were in response to well done issue reports.

Most of the new features haven't really required the degree of beta testing that you last saw here with the ram info option, which was and is an ugly solution to a problem with no good solutions. Battery for example went live with no issues at all because my hardware had revealed all the possible variances in data format, which was convenient.

I keep in touch with the debian packager, who is actually the ubuntu packager, he sends it upstream to debian's maintainer. I've honestly never understood why it takes more than a few days after a new release to get inxi into debian proper because inxi never has dependency issues, by design, so new inxi can always be dropped into any system, old, ancient, or new.

If you look closely at the inxi files, you'll discover that in fact, they pass lintian tests, which are the best and strictest packaging tests of any distro, I know, because inxi was in all the other distros before it got into debian, and I had to update the man stuff a bit to get it to pass lintian tests. This is an example of a good rule that benefits users, and one I am quite happy to go out of my way to get inxi to comply with, because it has clear and valid and logical and coherent benefits to users, packagers, and me. Unlike something that is badly done, helps nobody at all, and which is pointless and counterproductive, like, oh, say, git tagging. I've literally thought many times of dumping git and github so I don't have to entertain this nonsensical question ever again, but I figure the eyeballs in github make up for the annoyances of git users and their confusions about proper procedures. If it does ever get too annoying, I'll probably move to mercurial hosting, since git does me no personal good at all, it's a negative in every single way for me as a developer except for the eyeballs it gets in github, so I make that personal sacrifice. I'll see how it goes, I've learned to sort of hobble along with git, which is a really bad tool for my needs, so I basically just ignore it except for commits.

It's worth repeating that both git current, latest versions, and github provide a proper, correct, way, to point to commits directly, like it should have always done, as svn always did, so I believe the only people out of the loop on this question are people who haven't been paying much attention to the matter.

melmarker:
ok, i'm finally out of this game - forever.

PS: Thanks for your words - we will use from now the debian version.

Lanzi:
h2, this is really outstanding work. thank you very much!

Navigation

[0] Message Index

[*] Previous page