dmitriy.kazimirov/inxi
1
0
Fork 0
mirror of https://github.com/smxi/inxi.git synced 2024-11-16 08:11:39 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated Home (markdown)

smxi 2018-04-18 13:06:46 -07:00
parent ead80c9f64
commit 94157e7f73
1 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
Home.md

@ -12,20 +12,19 @@ The following are the resources available for inxi support, help, documentation,
* [inxi support forums](http://techpatterns.com/forums/forum-33.html) - post actual discussion type issues here, or use the issues tracker here, makes no difference, except the forum will be way more sticky and visible over time.
* [inxi issue tracker](https://github.com/smxi/inxi/issues) - use the github issue tracker/bug reporter to report issues/bugs.
* inxi IRC support: irc.oftc.net channel #smxi - sometimes IRC support is faster or more efficient.
* For git, the following branches are of interest:
* master - the master main branch. No other version of inxi than the current one in master is supported, so please upgrade your inxi to current before posting any issue or bug reports. See the installation instructions for how to do that.
* tarballs - a weak effort on my part to create a history of inxi. It's a collection of tarballs going back pretty much to the start of inxi, but they are randomly updated, and are NOT a reference point for packagers. They are a reference point for me and for anyone interested in how inxi grew and developed, nothing more.
* For git, the following branches are of interest (note: all pinxi/inxi branches support the -U self-updater command for easy updating once you have installed that branch. one and two would overwrite inxi master version, which is why they are almost never used):
* master - the master main branch. No other version of inxi than the current one in master is supported, so please upgrade your inxi to current before posting any issue or bug reports. See the installation instructions for how to do that. Devs: use inxi-perl pinxi since that is always either ahead or even with master.
* inxi-perl - this is the primary development branch, and uses pinxi to let you run inxi and pinxi on same system.
* one - alternate rarely used development branch for inxi.
* two - alternate, even more rarely used development branch for inxi.
* docs - this is the collection of html/css files that you'll find the [inxi documentation](http://smxi.org/docs/inxi.htm) in at [smxi.org](http://smxi.org/).
* one - this is a development branch, and is linked to by the inxi -! 11 updater, if there's a development version.
* bsd, gnubsd, two, three, android - these are rarely used development branches as well. two is updated locally by inxi -! 12.
* xiin - this is the great trash80 debugging tool, that lets inxi collect enough data to debug your issues.
* tarballs - a weak effort on my part to create a history of inxi. It's a collection of tarballs going back pretty much to the start of inxi, but they are randomly updated, and are NOT a reference point for packagers. They are a reference point for me and for anyone interested in how inxi grew and developed, nothing more.
If you have edits or changes for the smxi.org inxi documentation, you can file an issue here. The pages are in git here for your convenience, but please do not put those live anywhere else or google gets confused about which are the real versions. And please don't turn them into wiki pages elsewhere, people tend to do that once, then it gets stagnant and stale, but google doesn't know which is the real version, so please stick to the real documentation always.
## inxi debugging data requests
If you file a bug report, or issue, you will probably be asked to create and upload the inxi data debugger gz file. inxi uploads it automatically when you run the following command:
inxi -xx@ 14
the -xx part of it uplooads it, the -@ 14 part creates the actual debugging file.
inxi --debug 22
You are probably unlikely to get support in any real way if you are asked to provide this debugger data and don't do it, because the support time is cut by between 10 and 100 times on our end when the full debugger data is available, so if you won't provide it, we probably won't help you.
You are probably unlikely to get support in any real way if you are asked to provide this debugger data and don't do it, because the support time is cut by between 10 and 1000 times on our end when the full debugger data is available, so if you won't provide it, we probably won't help you.