From Fedora Project Wiki
(Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> =...")
 
Line 51: Line 51:
== Feedback ==
== Feedback ==


There has existed broad interest in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature.  Some of the distros configure their installations by default to talk to those servers, some do not.
There has existed [https://www.spinics.net/lists/fedora-devel/msg279002.html broad interest] in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature.  Some of the distros configure their installations by default to talk to those servers, some do not.


Turning on this by default has some limited privacy implications.  Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging.  The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo.  Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin.  In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy.
Turning on this by default has some limited privacy implications.  Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging.  The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo.  Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin.  In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy.

Revision as of 22:14, 6 April 2021


Change Proposal Name

Changes/DebuginfodByDefault

Summary

Fedora users / developers who need to debug/trace distro binaries can make use of the recently activated elfutils-debuginfod servers to automatically fetch debugging data and source code, instead of having to use # sudo dnf commands.

Owner


Current status

  • Targeted release: Fedora Linux 35
  • Last updated: 2021-04-06
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Numerous fedora debugging-type tools have built-in capabilities to use the debuginfod protocol to fetch debuginfo/source code automatically. We would like to activate a setting so that Fedora's debuginfod servers are automatically used, rather than requiring hand-editing individual users' dot files.

Feedback

There has existed broad interest in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature. Some of the distros configure their installations by default to talk to those servers, some do not.

Turning on this by default has some limited privacy implications. Some Debian users have expressed concerns that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging. The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo. Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is simply defaulted-on, and we have heard of no controversy.

We anticipate discussing this topic on the mailing list, and noting it in the release notes either way.

Benefit to Fedora

This will improve developers' experience.

It may reduce download server burden, as only individual ELF/DWARF/source files are downloaded rather than entire -debuginfo and -debugsource RPMs.

It would help Fedora catch up to other distros who put up debuginfod servers already. :-)

Scope

  • Proposal owners:

The work could consist of arranging for the elfutils-debuginfod-client RPM to install an /etc/profile.d file that sets the DEBUGINFOD_URLS environment variable automatically to https://debuginfod.fedoraproject.org/. (At the time of this writing, the _staging_ server is getting ready for testing: https://debuginfod.stg.fedoraproject.org/.)

  • Other developers: None - relevant code has been previously upstreamed!
  • Release engineering: None - our team is operating the debuginfod[.stg].fedoraproject.org VMs.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: N/A


Upgrade/compatibility impact

None.

Note that these servers index all active Fedora releases (32-), all architectures, so users of those versions can already set DEBUGINFOD_URLS manually to take advantage.

How To Test

  • Install elfutils-debuginfod-client
  • Open arbitrary fedora binary via gdb.
    • Admire the immediate downloading of debuginfo and source code.
  • Run eu-stack -v -p $pid for an arbitrary process.
    • Admire the immediate downloading of debuginfo to give precise file:line data.

User Experience

Primarily: users running debuggers, profilers, tracing tools on internet-capable machines can work immediately, without switching to privileged users and fragile manual dnf commands to install this data.

Dependencies

The debuginfod servers at fedora-infra need to be up.

Contingency Plan

  • Contingency mechanism: change the elfutils-debuginfod-client subrpm to not set the default DEBUGINFOD_URLS environment variable for all users. In the case of a server outage, the debugger tools revert to debuginfo-less operation, prior to this feature.
  • Contingency deadline: shortly before freeze
  • Blocks release? No

Documentation

There is upstream documentation in the debugging tools as well as associated with the client code / cli tooling. What our Release Notes would focus on however is the _automatic activation_ of this facility via the environment variable.

Release Notes

TBD.