Intern Introduction & Goals (Open 3D Engine)
by Nicholas Frizzell
Hello,
My name is Nicholas and I'm working this summer as an intern with Red
Hat. My primary objective this summer is to improve support for the
O3DE project (https://www.o3de.org/) in Fedora and eventually have it
packaged and available for install through the official repositories.
If anyone is interested in this topic or has any advice/suggestions to
help this project along feel free to reach out.
7 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
8 months, 1 week
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
8 months, 1 week
F39 proposal: Perl 5.38 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/perl5.38
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: <jplesnik(a)redhat.com>, <mspacek(a)redhat.com>
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* 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 ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
8 months, 3 weeks
libarrow (Apache Arrow) soname bump in Rawhide
by Kaleb Keithley
Hi,
Apache Arrow 10.0.0 has been released.
At present nobody is using libarrow except Ceph. (Which I am the maintainer
of.)
I will be rebasing libarrow to 10.0.0 within the next couple of days.
--
Kaleb
8 months, 4 weeks
Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
by Demi Marie Obenour
I noticed that by default, Qubes OS has voluntary kernel preemption
as opposed to full preemption. I found that enabling full preemption
(preempt=full on kernel command line) makes the system significantly
more responsive under heavy I/O load. In particular, if I build a
kernel in a Qubes OS VM, it significantly degrades responsiveness
without preempt=full. With preempt=full, the system remains
responsive. The storage stack used is LVM thin provisioning on LUKS,
and I have observed significant CPU usage in dom0 kernel threads with
names that indicate they are related to dm-thin and dm-crypt.
The kernel config used by the Qubes kernel package I use (6.1.28) is
based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd)
indicated that the same arguments apply to Fedora. Therefore, I am
asking if Fedora should use full kernel preemption by default.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
9 months
more distinct default bash prompt?
by Jens-Ulrik Petersen
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous
commands between long outputs when scrolling back in a terminal. Of course
in my own host I have a custom prompt, but it means whenever I am using a
different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
default, which I miss.
Since I spent a little time thinking about and investigating this I thought
I would write to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a
green one by default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at
least a very easy way to get one permanently (ie in a single command: even
if that were `dnf install bash-color-prompt` or running say `colorprompt`
once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or
customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
seems readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color
prompt?
Any better ideas or direction?
Jens
9 months, 2 weeks
Announcing fmt library soversion bump
by Vitaly Zaitsev
Hello.
fmt 10.0.x update will include a soversion bump from .9 to .10. It has
both API and ABI changes.
Changelog: https://github.com/fmtlib/fmt/releases/tag/10.0.0
The list of affected packages in Rawhide:
0ad
OpenImageIO
bear
cachelib
cantera
ceph
dnf5
dolphin-emu
domoticz
easyeffects
easyrpg-player
fb303
fbthrift
fizz
fmidi
folly
freeopcua
gerbera
giada
gnuradio
gr-funcube
libsemigroups
libsonata
luxcorerender
mcrouter
mkvtoolnix
nheko
proxygen
rstudio
sdrpp
spdlog
vcpkg
wangle
watchman
waybar
zswap-cli
I will use my proven-packager rights to rebuild all dependent packages
in a separate side tag next week.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9 months, 2 weeks
Proposal: drop delta rpms (for real this time)
by Matthew Miller
I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
priority. Last time we talked about this we didn't really get anywhere...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
... and that ticket hasn't moved, because fixing it isn't trivial.
What we're doing now — as has been the case for several years, already noted
in the previous discussion — has very little end-user value. Also as noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)
But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give DeltaRPMs a
sad, fond farewell.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9 months, 2 weeks
