Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [EN] inxi bugs or failures - please report  (Read 35758 times)

Offline h2

  • User
  • Posts: 64
    • smxi.org
[EN] Re: inxi bugs or failures - please report
« Reply #60 on: 2014/05/05, 19:56:13 »
I went back through my datasets and found some LXDE stuff, so I can remove one ambiguity, now it can search for /lxsession in ps aux, I believe that closes that.

Then inxi will show razor-qt until I get more logic.

I can add the tests for each type, but I still need the version data if it's present, I realized that inxi only shows the openbox version stuff.

on this one I"ll put a branches/one inxi, which you get by: inxi -! 15 (requires update enabled)

I'm also not clear on what this is in the first place, is LXQt the new LXDE, or are they two different thtings?
« Last Edit: 2014/05/05, 20:31:10 by h2 »

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #61 on: 2014/05/05, 20:40:42 »
hey :) - need to push the possibility ($foo --version) upstream :P Until now there is no such thing.

LXQt - The "new" one, based on Qt
LXDE - The gtk-based one - should be dead soon, but .. i think it will last for one or another year
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #62 on: 2014/05/05, 21:08:20 »
we'll see then.

it looks like both qt things, razor and lxqt identify themselves via xdg value as Razor.

I don't know if this is how it will be in the end.

Right now if xdg is 'LXDE' it shows as lxde, and if it's Razor, i can define it as either razor-qt or LXQt, but I know this is unlikely to remain the case.

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #63 on: 2014/05/05, 21:14:38 »
i think LXQt will be LXQt - until now the xdg name was Razor :) - Changed in Upstream 3 days ago i think
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #64 on: 2014/05/05, 21:21:14 »
ok, 2.1.28 should in theory work then.

I've added the xdg LXQt test too, so that means old lxde should id fine, and new lxqt/razor stuff should id fine, with razor-qt showing as that, and lxqt showing as that. I added one default case fallback where it will show LX-Qt-Variant if it failed to match any of the specific tests, so if you see that, it means we need more data.

Show me the new: inxi -Sxxx

in theory.

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #65 on: 2014/05/06, 20:43:37 »
Does 2.1.28 work for LXQt?

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #66 on: 2014/05/06, 20:45:51 »
stay tuned have neighter one or the other now :)
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #67 on: 2016/10/24, 05:58:51 »
Quote
Some time ago we talked about Virtualization support and at that time it was difficult to do without root.
Ofcourse there are some indirect hints like type of Graphics or Motherboard.

musca, if still around, this feature is now somewhat implemented as part of an -M fix for another issue. Note that the new Device: entry in the -M line covers device type, and if detected as possible vm, it tries to figure out which vm it is. This isn't perfect and will miss some vms probably but I added it remembering this very old feature request.

2.3.2 has the new device id. If you find any blatant failures in vm identification, let me know. The commonly used desktop vms should mostly work, except parallels and the microsoft vm, I'll probably try to figure out a non root way to id those as well but since they are apple and ms products I'm not heavily motivated, but I will add them if there is any actual issue posted on them with enough data to figure out how to reliably identify them with both non root system tests and dmidecode system tests (for bsd, old linux id purposes).

For systemd users, the id should work pretty well because it uses systemd-detect-virt plus some fallback tests, so I figure out of the box I probably handled maybe 98% of realworld virtual machine ids, most of the failures will be on BSDs I believe.

If it couldn't figure out which vm is it, but it is sure it's a vm, it prints: Device: virtual-machine

If it probably is a vm but it could not detect absolute proof, it will print: Device: other-vm?

For non vm, it prints things like desktop, server, laptop, notebook, etc. These will not all be right because they are based on what the system board dmi has, which is as we've seen with ram, often quite inaccurate. But it will be close in most cases. Obviously, for home built systems, if you make a server with a desktop mobo, it's not going to magically say server, it's going to say desktop, since that's what it actually is.
« Last Edit: 2016/10/24, 06:07:36 by h2 »

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #68 on: 2016/10/24, 13:23:16 »
hi h2 - i found a major bug :P - could you be so kind an tag your releases on github - if possible with a signed tag? If you have questions about the github release process please ping me.
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #69 on: 2016/10/24, 19:57:16 »
The github inxi readme covers tagging, as do several closed issues. That's not a bug, and it's most certainly not a major bug. I consider, personally, git tagging itself to be a major bug, and one that is so logically absurd that I find it almost mindboggling that users who should know better can't see what an absurdity it is. My general recommendation to anyone in a distro who relies on something that unreliable for anything is to file a bug report with the distro. github itself provides a very nice way to point directly to any commit, and I believe the new git also has that feature, which finally corrects the public belief that tagging is anything more than a crude poorly done hack. Just to briefly reiterate, since each and every inxi commit is the final stable version, each and every inxi commit would need a tag, which is silly, of course.

If there are issues related to vm identification, I'd like to get those covered, but git tagging, no, not interested.
« Last Edit: 2016/10/24, 20:01:05 by h2 »

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #70 on: 2016/10/29, 20:46:22 »
but it's nice to hear that inxi is still in development even if it will not reach the debianoid world
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline h2

  • User
  • Posts: 64
    • smxi.org
Re: inxi bugs or failures - please report
« Reply #71 on: 2016/10/29, 22:32:39 »
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: [Select]
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

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.
« Last Edit: 2016/10/29, 22:59:52 by h2 »

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: inxi bugs or failures - please report
« Reply #72 on: 2016/10/29, 23:33:05 »
ok, i'm finally out of this game - forever.

PS: Thanks for your words - we will use from now the debian version.
« Last Edit: 2016/10/29, 23:46:38 by melmarker »
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline Lanzi

  • User
  • Posts: 1.775
Re: inxi bugs or failures - please report
« Reply #73 on: 2016/10/30, 22:10:06 »
h2, this is really outstanding work. thank you very much!