The underlying system library in this case is /lib64/libncurses.so.6, which belongs to ncurses-libs package, so the simplest solution is:

yum install ncurses-libs-debuginfo

which indeed works out of the box, and provides the debug information.

I believe this is what gdb should suggest

(In reply to Przemek Klosowski from comment #1)
> yum install ncurses-libs-debuginfo

(1) yum is only a compatibility command which may/will go away, there is dnf instead now.

(2) With dnf it will not work unless you already installed one debuginfo rpm which automatically enabled the debuginfo repository. I do not know the details, one should test that on freshly installed Fedora. It is always changing with new versions of YUM/DNF. This is how it behaved with yum-plugin-auto-update-debug-info (which I still have installed, I do not know why when there is DNF and not YUM now). I do enable the debuginfo repositories by hand not relying on their automatic update by dnf/yum but one cannot expect that from a Fedora user.

(3) GDB prefers to use a package named based debuginfo installation (instead of build-id based debuginfo):
  Missing separate debuginfos, use: dnf debuginfo-install bash-4.4.23-1.fc28.x86_64
That GDB suggested build-id based debuginfo installation means that the package name lookup GDB tries somehow failed on your system.


(In reply to Przemek Klosowski from comment #0)
> recommends a dnf command to install the
> respective debuginfo package,

This is an unfinished work on its own. It was more intended GDB would run such command but that has never been finished (as there are many ways/frontends how users install packages and GDB should choose the right one).


> The install requires an unusual GPG key.

This is because that --enablerepo='*debug*' patten match is too general, I did not realize it may require the keys approval. It probably enabled rawhide-debuginfo repository or so. The problem is that releng still keeps changing the debuginfo repositories names, also in CentOS/RHEL variants which all GDB tries to address. So I ended up as '*debug*' as the most safe wildcard as I was thinking more repositories never hurt than less (but you have found one such disadvantage of enabling too many repositories).


> There is a much simpler install
> that provides the required debuginfo that uses regular, preinstalled key.

We can discuss using pros and cons of package names vs. build-ids but be sure the build-ids have more advantages than package names.


> Fedora user contributions to debugging should be as frictionless as
> possible, to promote wide participation in improving the code base.

Yes, there should be debuginfo server (resolving addresses/symbols) how Microsoft has and users should install no multi-gigabyte debuginfo packages to submit a bugreport. I may one day implement a debuginfo server for LLDB as it is not really implementable for GDB.


> Fedora has excellent infrastructure for this, but the .build-id system
> complicates it.

This Bug has been filed because of releng people are constantly changing the debuginfo repositories names and thus there is too general '*debug*' repository pattern now.  It is unrelated to build-ids.


> leading people to get used to blindly accept random security-related
> certificates.

One has to do that for the updates repository so all is lost then anyway.


> If the .build-id-based debuginfo is really necessary, the relevant GPG keys
> should be preinstalled.

Preinstalled does not solve anything when the installation media cannot be verified by a user before installing it.

I sure welcome signing etc. but I do not feel it is end-to-end safe currently.


But then this whole Fedora build-id patchset has been reworked for more seamless
upstreaming and so this Fedora patchset is in fact dead now and I am reluctant
to make more updates of it (although I sometimes had to do some).
  [PATCH v12 00/32] Validate binary before use
  https://sourceware.org/ml/gdb-patches/2015-08/msg00590.html
But its upstream approval process somehow died. And I am no longer working on GDB.

You wrote  
That GDB suggested build-id based debuginfo installation means that the package name lookup GDB tries somehow failed on your system.

This is strange---in the past GDB suggested debuginfo package installs, and I thought that the build-id method is somehow a new way that doesn't work well, hence the bug report. I could try to debug the lookup to see why it fails, but I have no idea why---can you suggest what to do?

# gdb /bin/get-versions
GNU gdb (GDB) Fedora 8.0.1-36.fc27
...
Reading symbols from /bin/get-versions...Reading symbols from /bin/get-versions...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install gpm-1.20.7-10.fc26.x86_64
(gdb) q
# dnf debuginfo-install gpm-1.20.7-10.fc26.x86_64
...
# gdb /bin/get-versions
GNU gdb (GDB) Fedora 8.0.1-36.fc27
...
Reading symbols from /bin/get-versions...Reading symbols from /usr/lib/debug/usr/bin/get-versions.debug...done.
done.
(gdb) start
...
Temporary breakpoint 1, main () at prog/get-versions.c:28
28	{
Missing separate debuginfos, use: dnf debuginfo-install ncurses-libs-6.0-14.20170722.fc27.x86_64
(gdb) _
...
# dnf debuginfo-install ncurses-libs-6.0-14.20170722.fc27.x86_64
...
# gdb /bin/get-versions
...
(gdb) start
...
(gdb) l winstr
474	../ncurses/lib_gen.c: No such file or directory.

So the debuginfo is installed. Another Bug is that debugsource is not installed:
  Bug 1494628.

I do not know what does not work on your system.
GDB tries to do:
$ rpm -q $(rpm -qf --qf '%{sourcerpm}-debuginfo.%{arch}\n' /lib64/libncurses.so.6|sed 's/\(-[^-]*-[^-]*\)\.src\.rpm-debuginfo\(.*\)/-debuginfo\1\2/')
And if it finds such debuginfo already installed (and the debuginfo still was not found) it will fall back to the build-id suggestion to be safe.

https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buildid-locate-rpm.patch

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

I cannot reproduce it anymore. Closing.