F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable
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 ==
Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions. This goes "all in" on being container-native and
significantly changes the technology and user emphasis.
== Owner ==
* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walters(a)verbum.org, jmarrero(a)fedoraproject.org, baude(a)fedoraproject.org
== Detailed Description ==
* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images
A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.
=== Backwards compatibility ===
If you're a user of ostree today: no need to worry. Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.
=== Stable Bootable OCI ===
More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation]. This Change highlights that this functionality is
planned to be officially stable.
=== Changing to OCI over the wire ===
Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.
These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.
* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)
An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image. Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.
Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)), but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.
The Fedora OSTree repository will become read-only and stop receiving updates.
Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263
==== Wire efficiency ====
Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see
* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/
However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.
=== dnf/yum CLI compatibility ===
rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today. A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense. A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:
<pre>
FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit
</pre>
*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.
To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`
subcommand on the client system.
For example:
<pre>
$ dnf image rebase quay.io/examplecorp/customos:latest
</pre>
As well as other offline/"image based" functionality such as `dnf
image rollback` and `dnf image apply-live`.
However, as many people know, rpm-ostree does today support
"per-machine" package layering/overrides - and *that will continue to
work*. So users are not *required* to do builds on a remote server
even in "image mode".
Concretely, it will also work to `sudo dnf -y install sway` inside a
root terminal on a Fedora Workstation for example. This will still be
a transactional operation.
More: https://github.com/coreos/rpm-ostree/issues/2883
=== Rebranding of rpm-ostree ===
This is a fundamental change in technology *and* positioning for
rpm-ostree (and for the projects that use it). The terminology of
"immutable" gets even fuzzier now (see also [this
blog](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisiona...).
It would make sense to rebrand the project due to this. No decision
has been made on this, but the choices are:
- Keep as is
- Rebrand to dnf-image (or, reviving a past name, yum-image)
- Rebrand to something else
More: https://github.com/coreos/rpm-ostree/issues/405
=== Support for building derivative containers ===
Until now, the model for systems like Fedora CoreOS and Silverblue
etc. has included an emphasis on containerization, but avoiding
extensive customization of the host system. This will be weakened
somewhat - it will be fully supported to build derivative operating
system images that in turn contain software which itself should run
directly on the host system, and not in a container.
A key aspect of this is that by generating a custom build, one binds
together the code and configuration as a transactionally updatable
unit.
The role of things like Kickstart, cloud-init, and Ignition and other
system config management shrinks significantly.
=== Example 1: Kubernetes and kubelet ===
It is not supported upstream to run the kubelet in a container image
itself. Today, for OpenShift 4 we embed the kubelet as part of the
CoreOS builds. The [https://www.okd.io/ OKD] project
[https://github.com/openshift/okd-machine-os/blob/fa2248d332abc9926e68428d...
already installs kubelet during a container build] deriving from the
base `fedora-coreos` image. It is possible that RHEL CoreOS will make
[https://github.com/openshift/os/issues/799 a similar split].
=== Example 2: Agent software ===
Many organizations require agents (cloud agents, security scanners,
antivirus) which are not ready to be containerized. Often too, these
tools come in e.g. RPM form, and also expect to be configured (remote
logging server, etc.). This tooling allows to `dnf install` these
*and* embed the configuration, generating a standard container image
which can then be booted as an atomic unit.
(Note that in the OpenShift context, we expect this to chain with the
first example - users instead derive from a `okd-node-base` image
which itself derives from `fedora-coreos`).
=== Example 3: Podman machine ===
The `[http://podman.io Podman]` project has a function called
`[https://github.com/containers/podman/blob/main/docs/source/markdown/podman-machine.1.md
machine]` where it creates a virtual machine and boots standard CoreOS
builds. Podman developers and users has long desired a custom FCOS
image that is focused on container deployment using Podman, including
certain QEMU packages that allow for cross-architecture development.
This approach will solve a series of problems including but not
limited to getting more timely release alignment between Podman and
FCOS.
We also have a user base that wants to customize the VM image based on
restrictive environments ... bring your own virtual machine image.
=== Support in Anaconda and other tools ===
Anaconda support for custom images is tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2125655
But, as part of this Change, it should also work to generate an
Anaconda ISO which allows *user choice* for whether to install in
"image mode" or "traditional".
=== Support for generating bootable images ===
Instead of using an existing disk image/ISO (Anaconda, AWS AMI, etc.)
and then doing an in-place update to a generated container image, in
many cases will want to generate disk images using their container
image as input.
For example, generating an ISO that embeds that container image as
input and will install it.
In this proposal, we plan to ship a container image as part of Fedora
CoreOS that will do this:
https://github.com/coreos/fedora-coreos-tracker/issues/1151
But, it also makes sense to have a tool that e.g. does this and
generates an Anaconda ISO (we will inherently be doing this as part of
generating ostree-based Anaconda ISOs already!) - this would just be
supporting that in a clear external way too. One likely target for
this is [https://github.com/osbuild osbuild] and
[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
RHEL Image Builder].
== Feedback ==
== Benefit to Fedora ==
The need to understand ostree goes away for most users; they
understand RPMs and containers. While retaining all the current
(rpm-)ostree features.
== Scope ==
* Proposal owners:
* Other developers: May affect e.g. gnome-software and similar tools
that talk to rpm-ostree.
* Release engineering: [https://pagure.io/releng/issue/11047]
* Policies and guidelines: None.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: None
== Upgrade/compatibility impact ==
We will ship a systemd unit that transitions systems currently using
OSTree on the wire over to tracking the corresponding container
images. Note again, all features of rpm-ostree continue to work! For
example, if you have layered packages, that will continue to be
applied.
== How To Test ==
Build container images, boot them.
== User Experience ==
Users will not need to understand ostree (at least at a superficial
level), only container images.
== Dependencies ==
Needs improvements in Anaconda in some cases, also would like to
increase alignment with dnf. Fetching container images uses `skopeo`,
maintained by containers team.
== Contingency Plan ==
* Contingency mechanism: Continue to ship things the way we ship them today
* Contingency deadline: Dunno
* Blocks release? No
== Documentation ==
https://coreos.github.io/rpm-ostree/container/ and
https://github.com/coreos/coreos-layering-examples etc.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
F37 proposal: Add -fno-omit-frame-pointer to default compilation
flags (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
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 ==
Fedora will add -fno-omit-frame-pointer to the default C/C++
compilation flags, which will improve the effectiveness of profiling
and debugging tools.
== Owner ==
* Name: [[User:daandemeyer| Daan De Meyer]], [[User:Dcavalca| Davide
Cavalca]], [[ Andrii Nakryiko]]
* Email: daandemeyer(a)fb.com, dcavalca(a)fb.com, andriin(a)fb.com
== Detailed Description ==
Credits to Mirek Klimos, whose internal note on stacktrace unwinding
formed the basis for this change proposal (myreggg(a)gmail.com).
Any performance or efficiency work relies on accurate profiling data.
Sampling profilers probe the target program's call stack at regular
intervals and store the stack traces. If we collect enough of them, we
can closely approximate the real cost of a library or function with
minimal runtime overhead.
Stack trace capture what’s running on a thread. It should start with
clone - if the thread was created via clone syscall - or with _start -
if it’s the main thread of the process. The last function in the stack
trace is code that CPU is currently executing. If a stack starts with
[unknown] or any other symbol, it means it's not complete.
=== Unwinding ===
How does the profiler get the list of function names? There are two parts of it:
# Unwinding the stack - getting a list of virtual addresses pointing
to the executable code
# Symbolization - translating virtual addresses into human-readable
information, like function name, inlined functions at the address, or
file name and line number.
Unwinding is what we're interested in for the purpose of this
proposal. The important things are:
* Data on stack is split into frames, each frame belonging to one function.
* Right before each function call, the return address is put on the
stack. This is the instruction address in the caller to which we will
eventually return — and that's what we care about.
* One register, called the "frame pointer" or "base pointer" register
(RBP), is traditionally used to point to the beginning of the current
frame. Every function should back up RBP onto the stack and set it
properly at the very beginning.
The “frame pointer” part is achieved by adding push %rbp, mov
%rsp,%rbp to the beginning of every function and by adding pop %rbp
before returning. Using this knowledge, stack unwinding boils down to
traversing a linked list:
https://i.imgur.com/P6pFdPD.png
=== Where’s the catch? ===
The frame pointer register is not necessary to run a compiled binary.
It makes it easy to unwind the stack, and some debugging tools rely on
frame pointers, but the compiler knows how much data it put on the
stack, so it can generate code that doesn't need the RBP. Not using
the frame pointer register can make a program more efficient:
* We don’t need to back up the value of the register onto the stack,
which saves 3 instructions per function.
* We can treat the RBP as a general-purpose register and use it for
something else.
Whether the compiler sets frame pointer or not is controlled by the
-fomit-frame-pointer flag and the default is "omit", meaning we can’t
use this method of stack unwinding by default.
To make it possible to rely on the frame pointer being available,
we'll add -fno-omit-frame-pointer to the default C/C++ compilation
flags. This will instruct the compiler to make sure the frame pointer
is always available. This will in turn allow profiling tools to
provide accurate performance data which can drive performance
improvements in core libraries and executables.
== Feedback ==
=== Potential performance impact ===
* Meta builds all its libraries and executables with
-fno-omit-frame-pointer by default. Internal benchmarks did not show
significant impact on performance when omitting the frame pointer for
two of our most performance intensive applications.
* Firefox recently landed a change to preserve the frame pointer in
all jitted code
(https://bugzilla.mozilla.org/show_bug.cgi?id=1426134). No significant
decrease in performance was observed.
* Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10%
regressions in some benchmarks
(https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/T/#u)
Should individual libraries or executables notice a significant
performance degradation caused by including the frame pointer
everywhere, these packages can opt-out on an individual basis as
described in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags.
=== Alternatives to frame pointers ===
There are a few alternative ways to unwind stacks instead of using the
frame pointer:
* [https://dwarfstd.org DWARF] data - The compiler can emit extra
information that allows us to find the beginning of the frame without
the frame pointer, which means we can walk the stack exactly as
before. The problem is that we need to unwind the stack in kernel
space which isn't implemented in the kernel. Given that the kernel
implemented it's own format (ORC) instead of using DWARF, it's
unlikely that we'll see a DWARF unwinder in the kernel any time soon.
The perf tool allows you to use the DWARF data with
--call-graph=dwarf, but this means that it copies the full stack on
every event and unwinds in user space. This has very high overhead.
* [https://www.kernel.org/doc/html/v5.3/x86/orc-unwinder.html ORC]
(undwarf) - problems with unwinding in kernel led to creation of
another format with the same purpose as DWARF, just much simpler. This
can only be used to unwind kernel stack traces; it doesn't help us
with userspace stacks. More information on ORC can be found
[https://lwn.net/Articles/728339 here].
* [https://lwn.net/Articles/680985 LBR] - New Intel CPUs have a
feature that gives you source and target addresses for the last 16 (or
32, in newer CPUs) branches with no overhead. It can be configured to
record only function calls and to be used as a stack, which means it
can be used to get the stack trace. Sadly, you only get the last X
calls, and not the full stack trace, so the data can be very
incomplete. On top of that, many Fedora users might still be using
CPUs without LBR support which means we wouldn't be able to assume
working profilers on a Fedora system by default.
To summarize, if we want complete stacks with reasonably low overhead
(which we do, there's no other way to get accurate profiling data from
running services), frame pointers are currently the best option.
== Benefit to Fedora ==
Implementing this change will provide profiling tools with easy access
to stacktraces of installed libraries and executables which will lead
to more accurate profiling data in general. This in turn can be used
to implement optimizations to core libraries and executables which
will improve the overall performance of Fedora itself and the wider
Linux ecosystem.
Various debugging tools can also make use of the frame pointer to
access the current stacktrace, although tools like gdb can already do
this to some degree via embedded dwarf debugging info.
== Scope ==
* Proposal owners: Put up a PR to change the rpm macros to build
packages by default with -fno-omit-frame-pointer by default.
* Other developers: Review and merge the PR implementing the Change.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]. A mass rebuild is required.
* 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 ==
This should not impact upgrades in any way.
== How To Test ==
# Build the package with the updated rpm macros
# Profile the binary with `perf record -g <binary>`
# Inspect the perf data with `perf report -g 'graph,0.5,caller'`
# When expanding hot functions in the perf report, perf should show
the full call graph of the hot function (at least for all functions
that are part of the binary compiled with -fno-omit-frame-pointer)
== User Experience ==
Fedora users will be more likely to have a streamlined experience when
trying to debug/profile system executables/libraries. Tools such as
perf will work out of the box instead of requiring to users to provide
extra options (e.g. --call-graph=dwarf/LBR) or requiring users to
recompile all relevant packages with -fno-omit-frame-pointer.
== Dependencies ==
The rpm macros for Fedora need to be adjusted to include
-fno-omit-frame-pointer in the default C/C++ compilation flags.
== Contingency Plan ==
* Contingency mechanism: The new version can be released without every
package being rebuilt with fno-omit-frame-pointer. Profiling will only
work perfectly once all packages have been rebuilt but there will be
no regression in behavior if not all packages have been rebuilt by the
time of the release. If the Change is found to introduce unacceptable
regressions, the PR implementing it can be reverted and affected
packages can be rebuilt.
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
* Original proposal for in-kernel DWARF unwinder (rejected):
https://lkml.org/lkml/2017/5/5/571
== Release Notes ==
Packages are now compiled with frame pointers included by default.
This will enable a variety of profiling and debugging tools to show
more information out of the box.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
Updating asio in rawhide (and possibly F37) to 1.24.0
by Julian Sikorski
Dear maintainers,
I have updated Fedora asio package from the current 1.16.1 to 1.24.0. I
have rebuilt the seven current dependencies and with the exception of
OpenSceneGraph, all build fine against the updated asio package. While
OpenSceneGraph failed to build, the failure does not seem to have to do
anything with asio.
I have created a side tag so that the rebuilds can be coordinated:
f38-build-side-56604. I do not have provenpacker privileges which means
you have to request the rebuilds yourself. You can start once the asio
build [1] finishes. Thank you for your cooperation in advance.
Best regards,
Julian
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90781633
1 year, 4 months
fedpkg clone fails with Permission denied (publickey).
by Richard Shaw
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
scratch.
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
real intuitive.
Thanks,
Richard
1 year, 4 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-10-31.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
Falcon orphan 4 weeks ago
adapta-backgrounds atim, orphan 1 weeks ago
bottles atim, orphan 0 weeks ago
capstone orphan, rebus, ret2libc 4 weeks ago
containerd copperi, go-sig, gotmax23, 1 weeks ago
orphan
dillo aarem, atim, orphan 3 weeks ago
fragments atim, orphan 3 weeks ago
geompp orphan 6 weeks ago
giada orphan 6 weeks ago
gnome-feeds atim, orphan 3 weeks ago
golang-github-anaskhan96-soup atim, go-sig, orphan 3 weeks ago
golang-github-beevik-etree go-sig, mgoodwin, nathans, 5 weeks ago
orphan
golang-github-crewjam-httperr go-sig, mgoodwin, nathans, 6 weeks ago
orphan
golang-github-crewjam-saml go-sig, mgoodwin, nathans, 6 weeks ago
orphan
golang-github-dchest-uniuri go-sig, mgoodwin, nathans, 6 weeks ago
orphan
golang-github-hajimehoshi-mp3 atim, go-sig, orphan 3 weeks ago
golang-github-hajimehoshi-oto atim, go-sig, orphan 3 weeks ago
golang-github-logr-stdr eclipseo, go-sig, orphan 5 weeks ago
golang-github-magefile-mage go-sig, mgoodwin, nathans, 5 weeks ago
orphan
golang-github-russellhaering- go-sig, mgoodwin, nathans, 6 weeks ago
goxmldsig orphan
golang-github-timberio-datemath go-sig, mgoodwin, nathans, 5 weeks ago
orphan
golang-github-tonistiigi- go-sig, orphan 1 weeks ago
opentelemetry-contrib
golang-github-ua-parser-uap go-sig, mgoodwin, nathans, 5 weeks ago
orphan
golang-modernc-ql go-sig, orphan 2 weeks ago
gydl atim, orphan 3 weeks ago
howl atim, orphan 3 weeks ago
llvm11.0 orphan, tstellar 3 weeks ago
moby-engine copperi, go-sig, gotmax23, 1 weeks ago
orphan
nautilus-search-tool orphan 6 weeks ago
python-APScheduler orphan, zuul 4 weeks ago
python-PyRSS2Gen orphan 3 weeks ago
python-charon orphan 5 weeks ago
python-hbmqtt orphan 6 weeks ago
python-hs-dbus-signature ignatenkobrain, jbaublitz, 4 weeks ago
orphan
python-pecan-notario orphan 4 weeks ago
python-phyghtmap orphan 0 weeks ago
python-pycdlib orphan 4 weeks ago
qextserialport orphan 0 weeks ago
rubygem-POpen4 orphan 2 weeks ago
rubygem-Platform orphan 2 weeks ago
rubygem-arel orphan 2 weeks ago
rust-base100 orphan, rust-sig 3 weeks ago
rust-dutree orphan, rust-sig 3 weeks ago
rust-heatseeker orphan, rust-sig 3 weeks ago
rust-jql orphan, rust-sig 3 weeks ago
rust-pommes orphan, rust-sig 3 weeks ago
rust-procs orphan, rust-sig 3 weeks ago
rust-tealdeer orphan, rust-sig 3 weeks ago
rust-varlink-cli orphan, rust-sig 3 weeks ago
rust-zoxide orphan, rust-sig 3 weeks ago
saga orphan 0 weeks ago
slv2 orphan, slaanesh 4 weeks ago
xchm orphan, wolfy 2 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2022-10-31.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
aarem: dillo
adamwill: capstone
adimania: moby-engine
akoutsou: capstone
amoralej: capstone
anthr76: containerd, golang-github-logr-stdr
apevec: capstone
astepano: moby-engine, capstone
atim: golang-github-anaskhan96-soup, gydl, gnome-feeds, howl, bottles,
golang-github-hajimehoshi-oto, dillo, fragments, adapta-backgrounds,
golang-github-hajimehoshi-mp3
bcl: capstone
berrange: capstone
bonzini: capstone
buckaroogeek: containerd, golang-github-logr-stdr
cleber: python-pycdlib
clumens: capstone
copperi: moby-engine, containerd, golang-github-logr-stdr
copr-sig: capstone
crobinso: capstone
dcantrell: capstone
dcavalca: containerd, golang-github-logr-stdr
ddd: capstone
dnglaze: capstone
dperpeet: moby-engine, capstone
dshea: capstone
dturecek: capstone
eclipseo: capstone, containerd, golang-github-logr-stdr
elmarco: containerd, golang-github-logr-stdr
eparis: containerd, golang-github-logr-stdr
epel-packagers-sig: capstone
ericb: capstone
etrunko: capstone
f1ash: capstone
fpokorny: containerd
frostyx: capstone
gicmo: capstone
go-sig: golang-github-beevik-etree, golang-github-anaskhan96-soup,
golang-modernc-ql, golang-github-magefile-mage,
golang-github-tonistiigi-opentelemetry-contrib, capstone,
golang-github-russellhaering-goxmldsig, containerd, golang-github-crewjam-saml,
golang-github-hajimehoshi-oto, moby-engine, golang-github-ua-parser-uap,
golang-github-dchest-uniuri, golang-github-logr-stdr,
golang-github-timberio-datemath, golang-github-crewjam-httperr,
golang-github-hajimehoshi-mp3
gotmax23: moby-engine, containerd, golang-github-logr-stdr
hno: capstone
hobbes1069: capstone
ignatenkobrain: python-hs-dbus-signature
imcleod: capstone
infra-sig: containerd
jamatos: python-PyRSS2Gen
jbaublitz: python-hs-dbus-signature
jchaloup: containerd, golang-github-logr-stdr
jforbes: capstone
jkastner: capstone
jsnow: python-pycdlib
juergh: capstone
kde-sig: capstone
kevin: capstone
kkoukiou: capstone
laine: capstone
larsu: capstone
libvirt-maint: capstone
lnie: capstone
lsm5: moby-engine, containerd, golang-github-logr-stdr
martinpitt: capstone
mattia: containerd
maxamillion: python-PyRSS2Gen
mcascella: capstone
mdbooth: capstone
merlinm: moby-engine, python-pycdlib, capstone
mgoodwin: golang-github-beevik-etree, golang-github-magefile-mage,
golang-github-russellhaering-goxmldsig, golang-github-crewjam-saml,
golang-github-ua-parser-uap, golang-github-dchest-uniuri,
golang-github-timberio-datemath, golang-github-crewjam-httperr
mikem: capstone
mikep: capstone
mmarusak: capstone
myoung: capstone
nathans: golang-github-beevik-etree, golang-github-magefile-mage,
golang-github-russellhaering-goxmldsig, golang-github-crewjam-saml,
golang-github-ua-parser-uap, golang-github-dchest-uniuri,
golang-github-timberio-datemath, golang-github-crewjam-httperr
ngompa: capstone
obudai: capstone
ochosi: capstone
olem: containerd, golang-github-logr-stdr
openstack-sig: capstone
osbuild-sig: capstone
packit: capstone
praiskup: capstone
puiterwijk: capstone
quintela: capstone
qulogic: capstone
raphgro: capstone
rebus: capstone
ret2libc: capstone
rjones: capstone
rmattes: capstone
rust-sig: rust-base100, rust-jql, rust-procs, rust-pommes, rust-tealdeer,
rust-zoxide, rust-dutree, rust-varlink-cli, rust-heatseeker
slaanesh: slv2
slagle: capstone
slp: capstone
strigazi: containerd, golang-github-logr-stdr
tdecacqu: capstone
tlavocat: capstone
tomegun: capstone
tstclair: containerd, golang-github-logr-stdr
tstellar: llvm11.0
vascom: capstone
veillard: capstone
virtmaint-sig: capstone
wolfy: xchm
wwoods: capstone
yanqiyu: containerd
zbyszek: capstone
zuul: capstone, python-APScheduler
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
Report finished at 2022-10-31 11:14:17 UTC
1 year, 4 months
Mesa in F37- vaapi support disabled for h264/h265/vc1
by Frantisek Zatloukal
Hi,
since this mesa change (
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373f...
) in F37 and rawhide, the mesa package lost support for vaapi accelerated
encoding and decoding of h264, h265 and decoding of vc1 (
https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open
source drivers (mainly AMD, maybe nVidia/other non x86...), that affects
common use-cases of Fedora Workstation, like watching videos, in-house game
streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in
Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion
addon to alleviate the fallout in the short term?
Thanks!
--
Best regards / S pozdravem,
František Zatloukal
Senior Quality Engineer
Red Hat
1 year, 4 months
CVE Tracking Bugs
by Maxwell G
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child, package-level bugs. I guess I could acomplish
what I'm proposing by filtering out mails with "X-Bugzilla-Product:
Security Response" headers and not have gone on this rant, but I still
think this needs to be addressed.
Does anyone know how to reach prodsec about this?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
1 year, 4 months
Fedora SCM requests on the weekend
by Robert-André Mauchin
Hello,
I know a lot of you are working on Fedora during the week days, but for some of us, the
weekend is the only time we can spend time on it. The problem is, SCM requests are rarely
processed during that time, most of them get stuck from Friday afternoon to Monday afternoon
(CEST), so it really hampers my work. Would it be possible for a volunteer to agree to do it
on the weekend.
Best regards,
Robert-André
1 year, 4 months
Re: Planning to start unifying native and mingw packages
by Sandro Mani
On 03.09.22 18:09, Richard Shaw wrote:
> On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com>
> wrote:
>
>
> On 03.09.22 17:10, Richard Shaw wrote:
> > I'm trying to migrate fltk right now and running into an issue:
> >
> > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> >
> > RPM build warnings:
> >
> > RPM build errors:
> > error: Could not open %files file
> > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
> such file
> > or directory
> >
> > Building the mingw packages seems to be interfering with the
> native build.
>
>
> I put %{?mingw_package_header} in the %{with mingw} (disabled)
> conditional this time and the build completed, so something in there
> is causing the issue.
You actually don't need %{?mingw_package_header} anymore at all (it
actually should just be a no-op with a current mingw-filesystem).
Sandro
1 year, 4 months
FontAwesome 6
by Jerry James
Hi all,
I would like to update the python-pydata-sphinx-theme package to its
latest version, but it needs FontAwesome 6.x. We currently have 4.x
in the fontawesome-fonts package and 5.x in the fontawesome5-fonts
package. Version 6.x has backwards compatibility helpers for both 4.x
and 5.x, so I would like to see fontawesome-fonts upgraded to 6.x and
the fontawesome5-fonts package retired. There are a few hurdles to
jump first.
One hurdle is that the current fontawesome-fonts maintainer doesn't
seem to have time to work on the package:
https://bugzilla.redhat.com/show_bug.cgi?id=1857488#c9. I'm willing
to help out with that, but would prefer to see somebody with more font
experience step into the main admin role.
Another hurdle is that you have to work a little to get the backwards
compatibility features for 4.x and 5.x. It isn't just a drop-in
replacement. I've started a COPR to work through the issues:
https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6/. This
shows both the python-pydata-sphinx-theme update I mentioned at the
top, and a patch for cantata to use 6.x natively.
Packages that need work:
- cantata (see the COPR for a possible solution)
- freeipa
- ipsilon
- python-XStatic-Font-Awesome [1]
- python-sphinx_rtd_theme (see
https://github.com/readthedocs/sphinx_rtd_theme/pull/1064)
- texlive-fontawesome
- texlive-fontawesome5
Packages with documentation built by python-pydata-sphinx-theme or
python-sphinx_rtd_theme may need to change font Requires:
- coq
- libgpuarray
- libsemigroups
- python-BTrees
- python-acme
- python-f5-sdk
- python-networkx
- python-notebook
- python-sphinx-ansible_theme
- python-streamlink
I'd appreciate any help the maintainers of these packages can offer,
as well as suggestions for improvements in what I already have.
Footnotes:
[1] Is this package needed? Nothing in Fedora seems to consume it.
It looks like it is just a bundled copy of the fonts, which also means
that its Requires on fontawesome-fonts and fontawesome-fonts-web are
wrong, since it contains the fonts.
--
Jerry James
http://www.jamezone.org/
1 year, 4 months