F35 Change: Debuginfod By Default (Self-Contained Change proposal)
by Ben Cotton
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
1 week, 1 day
future of dual booting Windows and Fedora, redux
by Chris Murphy
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer.
2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place.
The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849
It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)
c. Change the release criterion.
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_d...
Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.
Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.
d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.
Thoughts?
--
Chris Murphy
2 weeks, 1 day
some man pages have bugs, can't be grep'd
by Chris Murphy
I've been seeing this since clean installing Fedora 30. I don't recall
ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded
system (is now the clean installed system).
[chris@flap ~]$ man rpm | grep -C 10 rpmverbosity
<standard input>:176: warning [p 3, 0.8i]: cannot adjust line
[chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr
[chris@flap mantest]$ ll
-rw-rw-r--. 1 chris chris 62 Jul 16 14:24 rpm.stderr
-rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout
Is this a bug that should be reported against rpm or something else?
I'm certain I've seen it in other man pages, but offhand I can't find
another example.
--
Chris Murphy
2 months, 2 weeks
Unretire ulogd (or another NFLOG logger?)
by Chris Adams
I'd like to use NFLOG to log firewall drops (so that the kernel message
log isn't spammed by them), but it doesn't appear there's anything
currently in Fedora that can read that other than "tcpdump -i nflog".
It looks like ulogd was retired a while back because it only had a SysV
init script and nobody stepped up to convert it to systemd (which should
be really simple, since the old init script is pretty much a textbook
template of a SysV init script).
Am I missing anything? Is that all it needs? Is there another NFLOG
logger daemon?
--
Chris Adams <linux(a)cmadams.net>
3 months, 3 weeks
Co-maintainers for my ham packages
by Matt Domsch
Due to an impending move to NYC and related downsizing of my house into a
2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't
be able to test any of the Fedora packages I maintain with actual
hardware. Would anyone be interested in maintaining or co-maintaining
these?
- direwolf - Sound Card-based AX.25 TNC
- CubicSDR - Cross-Platform Software-Defined Radio Panadapter
- liquid-dsp - Digital Signal Processing Library for Software-Defined Radios
- sdrpp - SDRPlusPlus bloat-free SDR receiver software
- SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library
- soapy-rtlsdr - SoapySDR module for RTL-SDR hardware
Thanks,
Matt N5MLD
6 months, 3 weeks
Thoughts welcome: interface between automated test gating and the
"critical path"
by Adam Williamson
Hi folks!
I have one of those definitional quandaries and I figured I'd throw it
at the lists for some input.
Right now, we kind of take advantage of the "critical path" concept for
automated update testing and gating via openQA.
openQA does not test all updates, only critical path updates plus
updates containing any package on a short allowlist.
Bodhi and Greenwave do not gate all updates on the openQA tests since
not all updates are tested; again we use the critpath definition. If an
update is critical path, it gets gated on the openQA tests. If it
isn't, it doesn't.
If you've been paying attention, that means there's a bit of a hole:
the packages on the 'allowlist'. These are tested, but not gated.
What's on the allowlist? Basically, FreeIPA-related packages. We have a
good set of FreeIPA tests in openQA, and both I and the FreeIPA team
wanted relevant updates to be tested with them. But those packages are
not on the critical path. So I set up this 'allowlist' mechanism.
However, the lack of gating kinda sucks. I would much prefer if we
could gate these updates as well as just testing them.
The obvious thing to do is add the FreeIPA-related packages to the
critical path, but that really is not supported by the critical path
definition:
https://fedoraproject.org/wiki/Critical_path_package
which defines it as packages required to "perform the most fundamental
actions on a system", with a list of specific areas, none of which is
"run a domain server".
So...what to do?
I can think of I guess four options:
1. Broaden the definition of the "critical path" somehow. We could just
write in that it includes FreeIPA functionality, I guess, though that
seems special purpose. We could broaden it to include any functionality
covered by the release criteria, which would be quite a big increase
but seems like a reasonable and concise definition. Or we could write
in that it includes any functionality that is exercised by the gating
openQA tests, though that seems a bit arbitrary - there's no
particularly great organizing principle to the openQA tests we choose
to run on updates, if I'm honest, it's a sort of grab bag I came up
with.
2. Keep the current "critical path" concept but define a broader group
of "gated packages" somewhere (could be comps or somewhere else). This
would require engineering work - we'd have to touch probably the openQA
scheduler, Bodhi, and greenwave configs. It's also another maintenance
burden.
3. Add gating config to each allowlisted package repo's gating.yml one
by one. I don't really like this option. It'd be a chunk of work to do
initially, and multiples the maintenance required when the list of
tests to gate on changes for some reason.
4. Do nothing, just keep only gating things that are "critical path" on
the current definition. In a utopian future, we'd manage to deploy
openQA in the cloud or get a giant pile of super fast servers so we
could test and gate *every* update, and this wouldn't be an issue any
more.
What do folks think? Any preferences? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
10 months
Packaging a cross-compilation environment (wasi-libc)
by Jan Staněk
Hi list,
in order to be able to compile WASM natively on Fedora,
I'm trying to package wasi-libc[1] to provide the Web Assembly System
Interface.
[1]: https://github.com/WebAssembly/wasi-libc
My trouble is that this is in essence a cross-compilation environment,
and I have zero experience in trying to package these.
Also, I did not have much luck in trying to find any related
documentation.
Some issues I have run into so far:
- This is a libc implementation, which would probably conflict with the
glibc package by default. Looking at musl, the solution seems to be to
install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`).
Not really sure how this works, any pointers appreciated.
- Clang seems to have issue with `-fstack-clash-protection` flag for the
`wasm32-wasi` target. What's the proper way to adjust these?
Any additional tips on cross-compilation support in Fedora would also be
appreciated :)
Thanks in advance for any help!
--
Jan Staněk
Software Engineer, Red Hat
jstanek(a)redhat.com irc: jstanek
10 months, 1 week
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email: <tagoh(a)redhat.com>
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
<pre>
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272</pre>
<pre>
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
</pre>
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your
language>` and `fc-match monospace:lang=<your language>`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for most languages will be Google Noto fonts instead
of DejaVu, to keep consistency on the text rendering and to provide
better quality among languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
11 months, 2 weeks
