Bug#818876: read the text

[Adam Borowski]

> 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]  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.

Bug#818876: read the text

[Harald Hope]

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.

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.


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.


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.


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.


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]  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".


Or in this case, basic info like: what does it print out when you run inxi with the requested 
debugger option, -%


Then you, the user, find which files contains that string, and then you report which file it's 
coming from. 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.


So good luck with that, I apologize to unit193 and the debian maintainer, you 
can't win them all.

I'll give you a hint: this will never 'work' until you provide the data requested. And then it will 
simply expose almost certainly something you did. Not 100% certain, but very likely.


Out.