https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
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 ==
The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`.
When an RPM package is built, mtimes of packaged files will be clamped
to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest
`%changelog` entry. As a result, more RPM packages will be
reproducible: The actual modification time of files that are e.g.
modified in the `%prep` section or built in the `%build` section will
not be reflected in the resulting RPM packages. Files in RPM packages
will have mtimes that are independent of the time of the actual build.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew
Jędrzejewski-Szmek]]
* Email: mhroncok at redhat.com, zbyszek at in.waw.pl
== Detailed Description ==
This change exists to make RPM package builds more reproducible. A
common problem that prevents [https://reproducible-builds.org/ build
reproducibility] is the mtime (modification times) of the packaged
files.
Suppose we package an RPM package of software called `skynet` in
version `1.0`. Upstream released this version at datetime A. A Fedora
packager creates the RPM package at datetime B. Unfortunately, the
packager needs to patch the sources in the RPM `%prep` section. When
the build runs at datetime C, the modification datetime of the patched
file is set to C. When the build runs again in an otherwise identical
environment at datetime D, the modification datetime of the patched
file is set to D. As a result, the build is not bit-by-bit
reproducible, because the datetime of the build is saved in the
resulting package.
Patching is not necessary to make this happen. When a source file is
compiled into a binary file, the modification datetime is also set to
the datetime of the build. In practice, the modification datetime of
many files packaged in RPM packages is dependent on when the package
was actually built.
To eliminate this problem, we propose to clamp build mtimes to
`$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the
`$SOURCE_DATE_EPOCH` environment variable based on the latest
`%changelog` entry because the `%source_date_epoch_from_changelog`
macro is set to `1`. We will also set the
`%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when
files are packaged to the RPM package, their modification datetimes
will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry
datetime). Clamping means that all files which would otherwise have a
modification datetime higher than `$SOURCE_DATE_EPOCH` will have the
modification datetime changed to `$SOURCE_DATE_EPOCH`; files with
mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the
original mtimes.
This functionality is already implemented in RPM. We will enable it by
setting `%clamp_mtime_to_source_date_epoch` to `1`.
=== Non-goal ===
We do not aim to make all Fedora packages reproducible (at least not
as part of this change proposal). We just eliminate one problem that
we consider the biggest blocker for reproducible builds.
=== Python bytecode ===
When Python bytecode cache (a `.pyc` file) is built, the mtime of the
corresponding Python source file (`.py`) is included in it for
invalidation purposes. Since the `.pyc` file is created before RPM
clamps the mtime of the `.py` file, the mtime stored in the `.pyc`
file might be higher than the corresponding mtime of the `.py` file.
With the previous example, if `skynet` is written in Python:
# `skynet.py` is modified in `%prep` and hence has mtime set to the
time of the build
# `skynet.pyc` is generated in `%install` and the mtime of `skynet.py`
is saved in it
# RPM clamps the mtime of `skynet.py`
# `skynet.pyc` is considered invalid by Python on runtime, as the
stored and actual mtime of `skynet.py` don't match
To solve this, we will modify Python to clamp the stored mtime to
`$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream
Python chooses to invalidate bytecode cache based on hashes instead of
mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause
performance issues for big files, so Fedora's Python already deviates
from upstream behavior when building RPM packages. To avoid
accidentally breaking the behavior when
`%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and
buildroot policy scripts for creating the Python bytecode cache will
be modified to unset `$SOURCE_DATE_EPOCH` when
`%clamp_mtime_to_source_date_epoch` is not set to `1`.
This behavior might be proposed upstream if it turns out to be
superior to the current upstream choice, in case we
[https://discuss.python.org/t/14594 won't redesign the bytecode-source
relationship entirely] instead.
=== Opting out ===
Packages broken by this new behavior can unset
`%clamp_mtime_to_source_date_epoch` but packagers are encouraged to
fix the problem instead.
== Feedback ==
Enabling this RPM feature was
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/126
proposed as a pull request] to {{package|redhat-rpm-config}} in April
2021. It received good feedback with the exception of the following:
* it was said the change needs to be coordinated with the Python maintainers
* it was said the change should be done via a change process for
better coordination and exposure
We believe that by proposing this via the change process and planning
for the changes needed in Python, both issues are addressed.
== Benefit to Fedora ==
We believe that many RPM packages will become reproducible and others
will be more reproducible than before. The benefits of reproducible
builds are better explained at https://reproducible-builds.org/
== Scope ==
* Proposal owners:
** Propose a PR for {{package|redhat-rpm-config}} (set
`%clamp_mtime_to_source_date_epoch` to `1`, possibly only when
`%source_date_epoch_from_changelog` is set)
** Propose a PR for {{package|python-rpm-macros}} (unset
`$SOURCE_DATE_EPOCH` while creating `.pyc` files iff
`%clamp_mtime_to_source_date_epoch` is not `1`)
** Propose a PR for
[https://src.fedoraproject.org/rpms/python3.11/blob/b2d80045f9/f/00328-pyc-t…
the Python's bytecode invalidation mode patch] for all Python versions
that have it
** Backport (the new portion of) the patch to older Pythons
({{package|python2.7}}, {{package|python3.6}} and PyPys)
** Test everything together in Copr and deploy it if it works.
** Optional: Run some reproducibility tests before and after this
change and produce some statistics.
* Other developers:
** Test their packages with the new behavior, report problems, and
opt-out if really needed.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing anticipated.
== How To Test ==
The change owners plan to perform a mass rebuild in Copr to see if
this breaks anything significantly.
If it actually works as anticipated, they also plan to run some
reproducibility tests and hopefully produce some statistics before and
after this change.
Other packages can test by building their packages and verifying they
still work as expected and no packaged files have higher mtimes than
the last `%changelog` entry.
To verify if this change has landed, run: `rpm --eval
'%clamp_mtime_to_source_date_epoch'` on Fedora 38. The result should
be `1`.
== User Experience ==
Users of Fedora Linux on their machines should not be impacted at all.
Users who build RPM packages atop Fedora will be impacted by this
change the same way Fedora is.
== Dependencies ==
* RPM needs to support this (it already does)
* RPM needs to set `$SOURCE_DATE_EPOCH` (it already does)
== Contingency Plan ==
* Contingency mechanism: The change owners or
{{package|redhat-rpm-config}} maintainers or proven packagers will
revert the change in {{package|redhat-rpm-config}}. That should be
enough to undo anything as the changes in Python should be dependent
on that. If not enough, revert everything.
* Contingency deadline: Ideally, we should do this before the Mass
Rebuild. Technically, we can land it any time before the Beta Freeze,
but it would not change all the packages, which is a bit messy. *
Blocks release? No <
== Documentation ==
This page is the documentation.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
There will be an outage starting at 2022-11-30 21:00 UTC
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2022-11-30 21:00UTC'
Reason for outage:
We will be applying updates and rebooting servers. This will update some servers to RHEL8.7, some to 9.1 and we will be updating others to Fedora 37.
Affected Services:
A large number of services may be affected for short times in the outage window. Critical services (websites, mirrorlists) will be up the entire time.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11014
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
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 ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.
== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.
== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
<code>fedora-autofirstboot.service</code>
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/11148 #11148]
* 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 will have no impact on upgraded systems, since the firstboot
condition is not true in that case.
== How To Test ==
# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see <code>openh264</code> is installed and
<code>anaconda-core</code> is not.
== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.
== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.
== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.
== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/LLVM-16
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 ==
Update all llvm sub-projects in Fedora Linux to version 16.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 16, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang15 and llvm15 will be added to ensure that
packages that currently depend on clang and llvm version 15 libraries
will continue to work.
In addition, the default LTO mode for Fedora packages compiling with
clang will be changed from "Full LTO" to "Thin LTO". "Thin LTO" uses
much less compiler resources than "Full LTO", and is better tested and
supported by upstream. Note that this will not be a change to clang
itself, but rather a change to the compiler flags for clang in
redhat-rpm-config.
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build release candidates into @fedora-llvm-team/llvm16 COPR.
** Build final release (March 2023) into Rawhide and F38 branches.
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang15 and llvm15
compatibility packages if they want to rebuild their package and it
does not work with LLVM 16 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
16 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.
* Release engineering: [https://pagure.io/releng/issues/11150]
* 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 ==
== How To Test ==
== User Experience ==
== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 15 will need to
update their spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Contingency
mechanism: (What to do? Who will do it?): If there are major problems
with LLVM 16, the compatibility package provide a way for other
packages to continue using LLVM 15.
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 16:
llvm
clang
lld
lldb
compiler-rt
libomp
llvm-test-suite
libcxx
libcxxabi
python-lit
flang
mlir
polly
libclc
llvm-unwind
llvm-bolt
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
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-11-22.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
================================================================================
adapta-backgrounds atim, orphan 4 weeks ago
flam3 orphan 2 weeks ago
golang-github-anaskhan96-soup atim, go-sig, orphan 6 weeks ago
golang-github-containerd- go-sig, orphan 2 weeks ago
stargz-snapshotter
golang-github-fvbommel- go-sig, orphan 2 weeks ago
sortorder
golang-github-google- go-sig, orphan 2 weeks ago
containerregistry
golang-github-hajimehoshi-mp3 atim, go-sig, orphan 6 weeks ago
golang-github-hajimehoshi-oto atim, go-sig, orphan 6 weeks ago
golang-github-hanwen-fuse go-sig, orphan 2 weeks ago
golang-github-tonistiigi- go-sig, orphan 2 weeks ago
rosetta
golang-modernc-ql go-sig, orphan 5 weeks ago
javadocofflinesearch orphan 0 weeks ago
moby-engine copperi, go-sig, gotmax23, 4 weeks ago
orphan
python-cornice-sphinx infra-sig, orphan 1 weeks ago
python-fuckit orphan 2 weeks ago
qextserialport orphan 4 weeks ago
rubygem-POpen4 orphan 6 weeks ago
rubygem-Platform orphan 6 weeks ago
rubygem-arel orphan 6 weeks ago
rust-base100 orphan, rust-sig 6 weeks ago
rust-dbus-tokio orphan, rust-sig 0 weeks ago
rust-pommes orphan, rust-sig 6 weeks ago
saga orphan 1 weeks ago
switchboard-plug-tweaks orphan 2 weeks ago
toilet orphan 2 weeks ago
touchegg orphan 0 weeks ago
vorbisgain mavit, orphan 0 weeks ago
xchm orphan, wolfy 1 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2022-11-22.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):
adimania: moby-engine
astepano: moby-engine
athoscr: golang-github-hanwen-fuse
atim: golang-github-anaskhan96-soup, golang-github-hajimehoshi-oto,
golang-github-hajimehoshi-mp3, adapta-backgrounds
copperi: moby-engine
dcavalca: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
dperpeet: moby-engine
eclipseo: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse, golang-github-google-containerregistry
eparis: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
epel-packagers-sig: golang-github-hanwen-fuse
fab: golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta
fpokorny: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
go-sig: golang-github-containerd-stargz-snapshotter,
golang-github-google-containerregistry, golang-github-fvbommel-sortorder,
golang-github-hajimehoshi-oto, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse, golang-github-hajimehoshi-mp3,
golang-github-anaskhan96-soup, golang-modernc-ql, moby-engine
gotmax23: moby-engine
infra-sig: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse, python-cornice-sphinx
jchaloup: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
lsm5: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse, moby-engine
mattia: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
mavit: vorbisgain
merlinm: moby-engine
mikep: golang-github-hanwen-fuse
qulogic: golang-github-hanwen-fuse
rust-sig: rust-base100, rust-dbus-tokio, rust-pommes
wolfy: xchm
yanqiyu: golang-github-containerd-stargz-snapshotter,
golang-github-fvbommel-sortorder, golang-github-tonistiigi-rosetta,
golang-github-hanwen-fuse
--
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-11-22 20:38:46 UTC
https://fedoraproject.org/wiki/Changes/RemoveGuileFromGdb
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 ==
Remove Guile extension language support from the GDB package in favor
of the widely tested and feature-rich Python support
== Owner ==
* Name: [[User:keiths| Keith Seitz]]
* Email: keiths(a)redhat.com
== Detailed Description ==
The GDB package supports Python and Guile for writing extensions to
the debugger. The Python extensions are actively used by many
developers including the glibc developers for printing detailed POSIX
Thread information and by libstdc++ (gcc) developers for printing
developer friendly views of the standard library data structures. The
current Guile extension support is less actively used and this change
request proposes to remove that support from GDB.
== Feedback ==
Red Hat's Platform Tools team supports this change.
== Benefit to Fedora ==
GDB already supports a much more widely tested and feature-rich Python
interface<sup>1</sup>, and the GDB maintainers would like to remove
the maintenance burden imposed by supporting multiple scripting
interfaces. The Guile interface has already been disabled in RHEL9 and
onwards. This would align Fedora and RHEL and standardize the
community more directly on the Python interface for extension
development.
<sup>1</sup> The GDB User Manual states,
“[https://sourceware.org/gdb/current/onlinedocs/gdb/Multiple-Extension-Languages.html#Multiple-Extension-Languages
python comes first].” The Manual’s
[https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html#Python-API
Python] and [https://sourceware.org/gdb/current/onlinedocs/gdb/Guile-API.html#Guile-API
Guile] API pages demonstrate the disparity of support between these
two extension languages.
== Scope ==
* Proposal owners: Update gdb spec file.
* Other developers: Update GDB scripting files if using Guile.
Repository queries show no packages which rely on GDB that contain any
Guile source files.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* 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 ==
Users with Guile scripts will need to update and/or rewrite their
scripts in Python.
== How To Test ==
== User Experience ==
Guile scripts that extend the functionality of GDB will stop working
when users upgrade. Users are encouraged to use GDB's Python interface
instead.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
== Release Notes ==
Release notes should mention the removal of Guile support in GDB and
suggest alternatives.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
The UAPI group, a community for people with an interest in innovating
how we build, deploy, run, and update modern security-focused Linux
operating systems, will host a devroom at FOSDEM 2023.
A "devroom" (a FOSDEM term) is a co-located mini-conference with its
own separate track.
FOSDEM is a free event for software developers to meet, share ideas
and collaborate.
It takes place on February 4 and 5 at the ULB Solbosch Campus in
Brussels, Belgium.
Learn more at https://fosdem.org/2023/.
Our half-day devroom will open on Saturday morning and close at noon.
Drop in for talks on Image-based Linux and secure / attestable systems,
and for a chat with UAPI folks.
Call for Participation
We are looking for your talk proposals!
Talks are 20 minutes, on-site.
CfP deadline is Saturday, Dec 10, 2022.
Topics include:
- Image-based Linux distributions: intro, concepts, updates, differences with other distros
- OS and kernel image formats
- Cross-distro specifications and standards (e.g.: https://uapi-group.org)
- Trustable boot, device attestation, TPM usage and tooling
- A/B update implementations
as well as topics related to the above.
To apply:
1. Go to https://penta.fosdem.org/submission/FOSDEM23/event/new and fill in the proposal form.
If you don’t have an account yet, create one first.
2. In the submission form, make sure to select
Track: “Image-Based Linux and Secure/Measured Boot Devroom”
Event type: Presentation
Duration: 20 minutes
3. Add an abstract to both describe and to promote your talk.
4. Add / update your speaker bio at https://penta.fosdem.org/submission/FOSDEM23/person
Proposals will be accepted based on your abstract and speaker bio, please make sure both are in good shape!
For the latest updates on this devroom keep an eye on:
https://fosdem.org/2023/schedule/track/image_based_linux_and_secure_measure…https://uapi-group.org/docs/conferences/2023-02-04__fosdem-devroom/
--
Kind regards,
Zbigniew Jędrzejewski-Szmek
*# **FOSDEM 2023 Distributions Devroom - Call for Participation*
We're excited to announce that the Distributions Devroom is returning to
FOSDEM 2023, in-person in Brussels for the full day on Sunday, February 5.
The call for proposals is now open.
*## About the Distributions Devroom*
The Distributions Devroom is run by and for the people who build, package,
and contribute to distributions of Linux and other software. Distributions
remain a critical part of modern IT infrastructure, whether running on bare
metal or in containers, from supercomputers to edge deployments. The
Distributions Devroom provides a forum to share best practices on the
entire distribution lifecycle, from building and integration to long-term
support and security fixes.
*## Call for Proposals*
We welcome submissions targeted at contributors interested in issues unique
to distributions, especially in the following topics:
* Growing, participating, and working with communities around distributions
* Automating building and testing to minimize human involvement
* Cross-distribution collaboration on common issues
* Distribution construction, installation, deployment, packaging, and
content management
* Balancing new code and active upstreams versus security updates and
minimization of breaking changes
* Delivering architecture-independent software
* Working with vendors and including them in the community
* The future of distributions and emerging trends
* Non-engineering topics inside of distribution communities (e.g.
documentation, marketing, internationalization, design, community
operations, etc.)
* Creating a secure supply chain by evaluating upstream components and
providing a secure source for downstreams
*## Important Dates*
* Submission Deadline: Dec 20th 2022
* Acceptance notifications: Dec 31th 2022
* Final schedule announcement: Jan 14th 2022
*## Process*
1. Register a FOSDEM Pentabarf account[1] and sign in.
2. Visit the FOSDEM CFP[2] and click "Create Event".
3. Make sure "Track" is set to "Distributions devroom" for wranglers to
receive your submission!
4. Complete the form with your presentation details.
Make sure your submission has the following details:
* Title
* One-paragraph abstract
* Longer description including the benefit of your talk to your target
audience, including a definition of your target audience.
* Approximate length / type of submission (talk, BoF, …)
* Links to related websites/blogs/talk material (if any)
[1] https://penta.fosdem.org/user/new_account
[2] https://penta.fosdem.org/submission/FOSDEM23
*## About FOSDEM*
FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels. FOSDEM
hosts dozens of developer rooms, where community members run tracks on
various topics.
--
*Cheers*,
*Justin W. Flory* (*he/him*) || 📧 jwf(a)redhat.com || 🔗 jwf.io
*Fedora* Community Action & Impact Coordinator
TZ=America/New_York (UTC-4) 🕗
While I may be sending this email outside my normal office hours, I have no
expectation to receive a reply outside yours.
Now through 30 November, you may nominate candidates for the open
seats on the Fedora Engineering Steering Committee (FESCo).
To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.
For more information, see the Community Blog post:
https://communityblog.fedoraproject.org/f37-election-nominations-now-open/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/KDERemoveInitialSetup
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 ==
We currently don't use the initial-setup application in the main KDE
Spin and Kinoite installation ISOs as everything gets configured at
installation time via Anaconda. We thus want to remove this package
from the installation ISOs while keeping it where we currently need it
(pre-installed disk images, etc.). Note that an "initial setup" app is
still needed to enable OEM-style installations
(https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-…)
of the KDE Spin/Kinoite (like Fedora Workstation/Silverblue) so we're
planning on introducing a more KDE native application as a replacement
once it is ready, but that may not not happen as part of this change.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Ngompa| Neal Gompa]]
* Email: siosm(a)fedoraproject.org, ngompa(a)fedoraproject.org
== Detailed Description ==
We'll remove the initial-setup package from the KDE Spin & Fedora
Kinoite. This will fix a bug that is only visible on Kinoite (where
the user gets a warning on first boot because / is read only) and will
let us work on replacing it by another more KDE native application
instead.
OEM installations are installations where only the minimum is
configured by the vendor (hardware provider) and everything else is
done by the user on first boot. This is the default experience on
Fedora Workstation and other major operating systems. See also:
https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-….
Note that this is not about removing Anaconda as an installer or from
the Live ISO, but removing initial-setup. For Fedora Kinoite where we
don't have a Live ISO but a separate installer ISO that includes
Anaconda, this will effectively also remove Anaconda from the final
system.
See also the discussion in https://pagure.io/fedora-kde/SIG/issue/243
for potential alternatives.
== Feedback ==
None so far.
== Benefit to Fedora ==
* Smaller image
* One less UX bug on Kinoite
* Work in the direction of OEM installations for the KDE based variants
== Scope ==
* Proposal owners:
** Remove the packages and test the change. Work on packaging
alternatives and potential integration.
** OpenQA tests to update if we successfully enable the OEM installation mode.
* Other developers: N/A
* Release engineering: N/A
* 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 ==
Only impacts the first boot after installation. Should not impact updates.
== How To Test ==
Once the change has landed in Rawhide, downloading the ISO and
performing an installation should behave the same as currently. If we
successfully have a replacement then folks will be able to test OEM
installations.
== User Experience ==
No change initially. If we successfully have a replacement then we can
enable OEM installations.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the change.
* Contingency deadline: Anytime, probably before Beta
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
N/A. If we add OEM installation support then we can mention that.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis