Hi all,
I just pushed new Fedora Developer Portal release with changes from May,
it should become available in an hour, or until it properly propagates
through all the servers.
This release saw following updates:
* Update .NET docs for .NET 7 EOL
https://github.com/developer-portal/content/pull/540
* [Rust] Expand section about cargo + crate dependencies
https://github.com/developer-portal/content/pull/539
Thanks to the contributors.
If you find any problems or have an enhancement, feel free to submit an
PR or an issue on https://github.com/developer-portal/content
Regards,
Jarek Prokop
https://fedoraproject.org/wiki/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 ==
* Name: [[User:fche| Frank Ch. Eigler]]
* Email: fche(a)redhat.com
== Detailed Description ==
Numerous fedora debugging-type tools have built-in capabilities to use
the [https://sourceware.org/elfutils/Debuginfod.html 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
[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.
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 one extra parameter in the `elfutils.spec`
`%configure`. Its effect is to arrange 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.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
I prepared a new build of libxml that brings mainly minor fixes.
There is also a new major release/branch 1.3.x that breaks the API
compatibility, I keep that out of Fedora at the moment.
Tom
--
Tomáš Halman
thalman(a)redhat.com
T: +420 727 830 769 <+420727830769>
*../``\..* Red Hat <https://www.redhat.com/>
I am running into an odd issue where I am trying to rebuild the latest
version of the receptor package, and I able able to build on my local
system using mock for F40, F39 and EPEL9 but when I try building the same
RPMs in Koji one of the architecture always fails while the others are
successful. I am not sure if I am missing something that is causing my
builds to fail in Koji.
Example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=118572363
--
Sincerely,
Andrew Heath
aheath1992(a)gmail.com
Hi folks! This is just a heads up for update maintainers. You may have
noticed failures of ostree-related tests in openQA over the last few
days - rpmostree_overlay, rpmostree_rebase, or install_default_ostree.
These were caused by
https://bugzilla.redhat.com/show_bug.cgi?id=2284276 , which is now
resolved, and the tests are passing on current runs.
The ostree tests are not gating at present (this is because Silverblue
is still not release-blocking, though I might reconsider this choice at
some point since IoT *is* ostree-based and is release blocking). So
these failures are not preventing any updates going stable.
Given this, I'm not planning to re-run all the failures, because it'd
involve re-doing the image build test for every affected update and
each one ties up a worker for a couple of hours. So, you can expect the
failure to stay in the update results, but you don't really need to be
concerned about it.
If you really want the failure cleared from your update, let me know
and I can re-schedule the test for that update.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
Hi
In rpm 4.20 as currently available in rawhide, defining
__debug_install_post seems to have no effect. The %mingw_package_header
sets __debug_install_post as follows
%mingw_package_header \
%global __strip %{mingw_strip} \
%global __objdump %{mingw_objdump} \
%global __debug_install_post %%{mingw_debug_install_post} \
%{nil}
but %mingw_debug_install_post is never executed. Manually running
%mingw_debug_install_post
in %install works however.
Perhaps this is related to [1]? What is the correct way now to trigger
the custom debug extraction script?
Thanks
Sandro
[1] https://github.com/rpm-software-management/rpm/issues/2204