--- Begin Message ---
|
Subject: |
29.1; M-x gdb: don't ask me about debuginfod server if debuginfod is not in context |
|
Date: |
Sat, 04 May 2024 04:00:20 +0200 |
With 29.1 as well as with trunk(both tested with -Q) if I call M-x gdb I
get asked:
"Enable querying debuginfod servers for this session? (y or n)"
Even if I answer with "n" I get the message:
"No symbol \"debuginfod\" in current context."
This can't be right. Declining to use a feature should not be answered
with a message that it would not be available anyways (what the message
seem to tell me).
Digging around a bit it turns out there is a variable to customise the
behaviour here: gdb-debuginfod-enable-setting. Its default value is
'ask.
>From a user perspective it only make sense to be ask about wanting
something if this something is avaliable.
If it is about the advertising aspect then why not more clear don't ask
questions and instead write a message like: "You cannot use debuginfod
servers. Consider using this marvelous feature".
rolf
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#70764: 29.1; M-x gdb: don't ask me about debuginfod server if debuginfod is not in context |
|
Date: |
Sat, 18 May 2024 11:36:21 +0300 |
> Cc: 70764@debbugs.gnu.org
> Date: Sat, 04 May 2024 20:07:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > (gdb)
> > -gdb-set debuginfod enabled on
> > ^error,msg="No symbol \"debuginfod\" in current context."
> > (gdb)
> >
> > So, this all seems to lead to that the gdb shipped with Bullseye isn't
> > correctly
> > build (despite the --with-debuginfod in the gdb --config output).
>
> Most probably, yes.
>
> > But Bullseye still isn't that uncommon; so others should also see this, I
> > suppose?
>
> Unfortunately, the only better alternative to stop these error
> messages is for you to customize gdb-debuginfod-enable-setting to the
> nil value. That is the only way we know of that allows to prevent the
> error messages by avoiding to even try the problematic setting. No
> other way we tried at the time to dynamically detect the support
> worked in a satisfactory manner, basically because trying an
> unsupported command is bound to trigger some error message.
No further comments within 2 weeks, so I'm now closing this bug.
--- End Message ---