> Adam, I'm going to ignore this now, because you are refusing to do a few > things: > > 1. one, you aren't providing the requested debugging information.
Because you haven't actually sent me any such request. I have only now randomly viewed the bug report. As per the BTS documentation: # n...@bugs.debian.org — such messages are also sent to the package # maintainer and forwarded to debian-bugs-dist, but not to the submitter; # nnn-submit...@bugs.debian.org — these are also sent to the submitter and # forwarded to debian-bugs-dist, but not to the package maintainer; # nnn-mainto...@bugs.debian.org — these are only sent to the package # maintainer, not to the submitter or debian-bugs-dist; # nnn-qu...@bugs.debian.org — these are only filed in the bug tracking # system (as are all the above), not sent to anyone else. You'd need -submitter or a manual CC. > 2. two, you keep believing that the fallback /etc/issue is the default > value being printed, for no actual reason I can see other than you believe > it's the case, when it's the exact opposite, > /etc/issue is used if and only if all other tests have failed. All. This > means you have no etc/debian_version, no /etc/os-release, no > /etc/lsb-release, all have been removed from the system. > In other words, you are not running a standard debian system, obviously. [~]$ cat /etc/debian_version stretch/sid [~]$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux stretch/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; > I can't really make it any more clear, /etc/issue is used if and only if > ALL other possible distro identification methods have failed. It makes no > difference what you want to believe or state about this, and if you provide > no debugging data, this bug should be closed, since the poster has not added > a word that contributes to fixing any potential issue. /etc/issue is not meant to be used in this way, so you need to expect random information there. If you want to use it as a fallback, you need to at least make some sanity checks, like removing ANSI codes, etc. > 3. you aren't even providing the requested debugger info for inxi, which > is: inxi -S -% so we can see what is actually being suppressed, and from > where. System: Host: umbar Kernel: 4.4.5-x32 x86_64 (64 bit) Desktop: Xfce 4.12.3 Distro: %y^\\. (/// .\)) (((( ^ )))) (((|)_=_/((() ))))) ()))) / | . \ / (* ^ *) \ compiled / /|`--" `--"|\ \ / ." --. . --. ". \ __/ / /( \ / )\ \ \__ /-- ' ( \ y / ) ' --\ \ "./ " / `--/ /\--" / _) \ mm/ (_ \ \_b Debian GNU/ unstable Doesn't look like useful debug data, I'm afraid. > Since these things take seconds to do, I assume you have some valid reason > for not providing the data requested while continuing to talk about things > that have no meaning for this issue in all likelihood. > > My apologies to the maintainer, there's nothing I can do for you here > since the user refuses to provide any meaningful feedback. I'm not omniscient, the only request I've seen is from a BSD guy. > Saying "It's not working in 2.2.28" is absurd, this has nothing to do with > 2.2.28, zero. Let me quote from the great Debian IRC factoid: > > !doesn't work > [16:45] <Bot`> user: doesn't work is Look buddy, "doesn't work" is a vague > statement. Does it sit on the couch all day long? Does it procrastinate > doing the dishes? Does it beg on the street for change? Please be > specific! Define 'it' and what it isn't doing. Give us more details so > we can help you without needing to ask basic questions like "what's the > error message". That's valid only without context. The context here is provided in the bug report. > Or in this case, basic info like: what does it print out when you run inxi > with the requested debugger option, -% CPU~Hexa core AMD Phenom II X6 1055T (-MCP-) speed/max~800/2800 MHz Kernel~4.4.5-x32 x86_64 Up~2 days Mem~2488.1/7988.3MB HDD~1240.3GB(84.1% used) Procs~240 Client~Shell inxi~2.2.28 > Then you, the user, find which files contains that string, and then you > report which file it's coming from. Which string? Nothing in the output of "inxi -%" seems relevant to distro detection. > Then, as a debian user, you would explain why the standard debian release > files, /etc/debian_version and /etc/os-release have been removed from your > system. Both are present, with contents as I quoted above. -- A tit a day keeps the vet away.
