Are we ready for ipv6-mostly networks?
by Petr Menšík
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
What do you think about it?
[1] https://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
12 months
F39 Proposal: Make Toolbx a release-blocking deliverable and have
release-blocking test criteria (System-Wide Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker
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 ==
Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] [https://opencontainers.org/ OCI] images must be
published on [https://registry.fedoraproject.org/
registry.fedoraproject.org] as release-blocking deliverables, and
there must be release-blocking test criteria to ensure usable
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs.
== Owner ==
* Name: [[User:Rishi|Debarshi Ray]], [[User:Sumantrom|Sumantro Mukherjee]]
* Email: debarshir(a)redhat.com, sumukher(a)redhat.com
== Detailed Description ==
Currently, there is no formal requirement for
[https://containertoolbx.org/ Toolbx] to be usable when a new Fedora
is released. This is a problem for a tool that's so popular and
provides something as fundamental as an interactive command line
environment for software development and troubleshooting the host
operating system. This Change aims to address this.
Toolbx has two parts — an [https://opencontainers.org/ OCI] image,
which defaults to
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] on Fedora hosts, and the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPM. The OCI
image is pulled by the RPM to set up a containerized interactive CLI
environment.
First, we want to ensure that there are up to date
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] OCI images published on
[https://registry.fedoraproject.org/ registry.fedoraproject.org] as
release-blocking deliverables at critical points in the development
schedule, just like the installation ISOs for the Editions from
[https://download.fedoraproject.org/pub/fedora/linux/releases/
download.fedoraproject.org]. This must at least happen when an
upcoming Fedora release is branched from Rawhide, and for the Beta and
Final release candidates. If possible, they should be updated more
frequently as part of the nightly composes. We do not expect this to
happen after a Fedora release has gone GA.
Second, we want to have release-blocking test criteria to ensure
usable [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs at
critical points in the development schedule. This must be used to
ensure that both changes in the Toolbx stack, and future
[https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Changes] in other parts of the OS do not break Toolbx, and at least
cover the Beta and Final release candidates.
Examples of changes in the Toolbx stack causing breakage can be
[https://bugzilla.redhat.com/show_bug.cgi?id=2183034 FUSE] preventing
RPMs with file capabilities from being installed inside Toolbx
containers, Toolbx [https://github.com/containers/toolbox/issues/643
bind mounts] preventing RPMs with <code>%attr()</code> from being
installed or causing
[https://bugzilla.redhat.com/show_bug.cgi?id=2188304
systemd-tmpfiles(8)] to throw errors, etc.. Examples of changes in
other parts of the OS can be changes to Fedora's Kerberos stack
causing Kerberos to stop working inside Toolbx containers,
[[Changes/EnableSysctlPingGroupRange|changes]] to the
<code>sysctl(8)</code>
[https://github.com/systemd/systemd/commit/90ce7627dfe824ff6e7c0ca5f96350f...
configuration] breaking ping(8), changes in
[https://github.com/containers/toolbox/issues/562 Mutter] breaking
graphical applications, etc..
Note that having release-blocking test criteria for the
<code>toolbox</code> RPM will also implicitly test the
<code>fedora-toolbox</code> image.
== Feedback ==
== Benefit to Fedora ==
This Change improves the quality of the containerized interactive
command line [https://containertoolbx.org/ Toolbx] environments on
Fedora by adding formal requirements to ensure that they are usable
when a new Fedora is released. This will bring them closer to the
reliability of similar environments running directly on the host
operating system.
Toolbx is installed by default on CoreOS, Silverblue and Workstation.
It is indispensable for software developers using Silverblue to bypass
the difficulty of setting up a development environment in the usual
way. It is widely used, even on Workstation, by those who don't want
to pollute their host OS, or want to access a CLI environment that's
different from the host's without installing a virtual machine, or
want a pre-configured development environment.
It will be beneficial to consider the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images as release-blocking deliverables because
Fedora's [https://opencontainers.org/ OCI] infrastructure is often
broken. Here are [https://pagure.io/releng/issue/11092 two]
[https://pagure.io/releng/issue/11367 recent] examples of <code>fedpkg
container-build</code> not working. In the second case, it was
preventing the images from being rebuilt to pull in an
[https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important]
bug-fix. The broken infrastructure prevents regular Fedora
contributors from jumping in to rebuild and publish the images at
critical points in the development schedule. Making them
release-blocking deliverables would attract greater attention and
scrutiny from release engineering and ensure that a Fedora development
cycle does not proceed with broken or outdated or missing
<code>fedora-toolbox</code> images.
At the moment, the branching of an upcoming Fedora release from
Rawhide is a particularly chaotic time. Since the
<code>fedora-toolbox</code> images for Fedora Branched and Rawhide are
not rebuilt as part of the branching process, there is a lot of
confusion for end-users until someone manually rebuilds the images and
gets them published, which can take some time as described above.
Having the images built and published by release engineering as part
of the branching will avoid this.
If someone installs the Beta or the Final on their host, and creates a
Toolbx container using the default <code>fedora-toolbox</code> image,
then, barring exceptions, the host and the container will have the
same RPM versions. Just like Workstation and Silverblue are released
with the same versions. This will ensure greater consistency in terms
of bug-fixes, features and pending updates.
Last but not the least, we cannot have release-blocking test criteria
for the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs
unless the images are also release-blocking deliverables, because the
RPMs depend on the images. This brings us to the benefits of the
second part of this Change.
It will be beneficial to have release-blocking test criteria for the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs because they
interact with different parts of the OS to set up the containerized
interactive CLI environments. These environments have seamless access
to the user’s home directory, the Wayland and X11 sockets, networking
(including Avahi), removable devices (like USB sticks), systemd
journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc.,
and any unexpected change in another part of the OS can break the
environment.
The release-blocking test criteria will be a way to co-ordinate
several disparate groups of developers to ensure that the
containerized interactive CLI Toolbx environments on Fedora are just
as reliable as those running directly on the host OS.
== Scope ==
* Proposal owners: Write down the release-blocking test criteria for
the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs that
will be used for testing and the blocker bugs process.
* Other developers: The release-blocking test criteria for Toolbx will
require others to debug and fix bugs, possibly blockers, and be
mindful of making changes to other parts of the operating system that
break the Toolbx environment.
* Release engineering: [https://pagure.io/releng/issue/11399 #11399]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/449 #449]
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
This is only a change to the Fedora release processes. Therefore,
systems with a previous version of Fedora won't need any manual
intervention.
There should not be any user-visible change, other than, barring
exceptions, the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] image having the same RPM versions as the host at
critical points in the development schedule, fewer bugs and a more
reliable Toolbx.
== How To Test ==
Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images must be available from
[https://registry.fedoraproject.org/ registry.fedoraproject.org] when
an upcoming Fedora release is branched from Rawhide, and for the Beta
and Final release candidates. The following steps can be used to test
this:
* Check the Toolbx containers and images present locally using
<code>toolbox list</code>.
* Remove any Toolbx containers and images for the Fedora release under
development using <code>toolbox rm</code> and <code>toolbox
rmi</code>.
* Create a new Toolbx container with <code>toolbox create</code> and
enter it with <code>toolbox enter</code>.
* Use <code>sudo dnf update</code> inside the Toolbx container.
Barring exceptions, the container should have the same RPM versions as
the host.
The [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs must
satisfy the test criteria for the Beta and Final release candidates.
Writing the test criteria is part of this Change, so they don't exist
at the moment, but likely examples can be:
* Graphical Apps running inside Toolbx container should be accessible outside
* Graphical Apps (text editors) should retain their state even when
the virtual terminal is closed
== User Experience ==
This Change improves the quality of the containerized interactive
command line Toolbx environments on Fedora by ensuring that they are
just as reliable as those running directly on the host operating
system.
If someone installs the Beta or the Final on their host, and creates a
Toolbx container using the default
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] image, then, barring exceptions, the host and the
container should have the same RPM versions. Just like Workstation and
Silverblue are released with the same versions. This will ensure
greater consistency in terms of bug-fixes, features and pending
updates.
== Dependencies ==
N/A (not needed for this Change)
== Contingency Plan ==
* Contingency mechanism: If there are no up to date
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images published on
[https://registry.fedoraproject.org/ registry.fedoraproject.org] as
release-blocking deliverables, then the release-blocking test criteria
for the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs
cannot be put into production. In that case this Change cannot be
implemented and status quo will be maintained. If the images get
published, but the test criteria is absent, then only the first half
of the Change will be implemented, and users can still benefit from
the more predictably updated images.
* Contingency deadline: We need this by the Change completion deadline
or before Fedora 39 is branched from Rawhide, whichever is earlier. As
per the [https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
schedule], both of those are currently set to happen on the 8th of
August 2023.
* Blocks release? No
== Documentation ==
* Toolbx basics: https://containertoolbx.org/install/
* Toolbx manuals: https://github.com/containers/toolbox/tree/main/doc
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
12 months
Self Introduction: Andreas Vögele
by Andreas Vögele
Hello Fedora developers,
I'm Andreas from Stuttgart in Germany. I'm a system administrator and
software developer, who moved his computers to Fedora about a year ago.
I've written a handful of Perl modules that I package at the Open Build
Service and Copr. I'd like to maintain some of these modules directly in
Fedora. In the past, I maintained ports of other software at
SlackBuilds.org and OpenBSD. Occasionally, I contribute patches to free
software projects. I enjoy programming in C, Perl and recently Kotlin.
Kind regards,
Andreas
12 months
Self Introduction: Herald Yu
by Herald Yu
Hello everyone, I am Herald come from Shanghai, China. It's nice to meet you in Fedora Devel Community.
I am a Tech Writer who is passionate about open-source technology. I have contributed to JuiceFS and I am willing to package and maintain this software package. I hope to join the Fedora developer community, learn from everyone, and contribute to the development of the Fedora ecosystem.
If you would like to know more information about me, I am willing to further introduce myself to everyone.
12 months
Old stalled bodhi updates
by Mikel Olasagasti
Hi all,
There are currently 157 updates in testing or pending status in Bodhi
that were created before 2023:
https://bodhi.fedoraproject.org/updates/?search=&submitted_before=2023&st...
There are 7 Fedora updates, 6 for Fedora-37 and one in
pending->testing status for Fedora-35. The rest are for EPEL-7 and
EPEL-8, mostly from before 2022, so I guess as those releases are
still active the updates are not auto-closed.
Can those old updates be unpushed? If so, who should take care of it?
Kind regards,
Mikel
12 months
Schedule for Tuesday's FESCo Meeting (2023-05-30)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2023-05-30 17:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
Change: LIBFFI_34_static_trampolines
https://pagure.io/fesco/issue/3001
APPROVED (+3, 0, -0)
Change: Fedora Onyx
https://pagure.io/fesco/issue/2996
APPROVED (+4, 0, 0)
= Followups =
#2993 Change: Increase vm.max_map_count value
https://pagure.io/fesco/issue/2993
= New business =
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
-----BEGIN PGP SIGNATURE-----
iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAmR2Fn0ACgkQRduFpWgo
bRGmSwv+O26i60w29yXSIe+GKyQnc/f26pwNXKmRSIvgkRwFgN31VdOGR5uQHljX
Mbv9WDZrdWf8vDeKEu/gQZNHK2jTHq0M3GSBTkSsWOKcNcvhgTFRO7PdknTTgXS5
46wzGYCu5QGwChkVPugHlLmvXm/EUzgbZ7LGGeimL/CBRrashO+AmHMCQ580NuCc
Kls6m1OVnNOTeoqEUs1hxynvXj+XVC3C16BLDPCwWGhh6lohaygzupPLEBc5lDlc
asSEfwxuUYrdkzlSBk2zYRaP+VThbf/I/cepR1irl3DdmE7mJIGXk5bIi16i32T1
qZTPPidTOnwKUBd7UEPHrpMWHHpy//BK+phJfB5yZNX4K8jNaOH9n2GIrxOBZ1I3
7Rfp/PZsaSO7GKkJbfIdMUbkriE6s6Zok4dCk5yU8dDCLrFEXbFld51khVXnUlbS
hgiWxvXYguDK+JzAT6r+CpDLlGS67/Qny3RljhZbFzong5WsMhYvlUCoa49QPxJN
NpOhVpbh
=dyVy
-----END PGP SIGNATURE-----
1 year
employment related packager groups
by Kevin Fenzi
Greetings everyone.
Today we have packager groups used in src.fedoraproject.org to allow a
group of people to maintain packages. In the past this has been used for
SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
like.
FESCo has been asked about creating company related groups.
( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
ie, foocorp-sig / foocopr-packagers. These groups would then be used to
help maintain packages that foocorp finds of interest/value.
This would help companies manage the people they pay to contribute.
It would allow them to more easily add/remove employees as time goes on
instead of someone having to go and add/remove someone from a bunch of
packages.
So, I promised to start a thread here about this.
Should such groups require FESCo approval?
If so, what would be requirements to approve/deny?
Should we require some documentation? ie, should the group have to make
a doc/wiki page explaining what it's for and how to reach group owners
in case of problems?
Thoughts?
kevin
1 year
F39 Change Proposal: Retire AWS CLI version 1 package awscli (System
Wide Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AwsCli
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 ==
As a result of the publication of the
[https://bugzilla.redhat.com/show_bug.cgi?id=2189420 awscli2] package,
the original version of 'awscli' is no longer necessary. This would
mark the retirement of the original AWS CLI package version in favor
of the awscli version 2. The AWS CLI version 2 is the most recent
major version of the AWS CLI and supports all of the latest features.
Some features introduced in version 2 are not backported to version 1
and users must upgrade to access those features.
== Owner ==
* Name: [[User:davdunc| David Duncan]] [[User:limb | Gwyn Ciesla]]
* Email: davdunc at amazon dot com, gwync AT protonmail DOT com
== Detailed Description ==
The AWS CLI v2 has been
[available](https://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-gener...
for more than 2 years. There has been a considerable amount of
discussion around the decisions made upstream and attempts to create
collaborative efforts with the new Amazon Linux 2023 led to a lot of
discussions related to the supporting libraries included in the
[https://awslabs.github.io/aws-crt-python/index.html AWS Common
Runtime] bindings. It took a long time to find a model that was
consistent and appropriate. A fair amount of effort went into building
this on multiple occasions. Nikola Forro completed work on the package
integration and is actively working on support for packit with the
upstream providers. Since the awscli version is in what we would
consider a maintenance phase, there are many new services and features
that are not available without the awscli2. See the
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes....
new features and changes] in the 'Migration Guide' section of the AWS
Documentation for more details on variations in the functionality and
moving your workflow to the later release.
== Feedback ==
== Benefit to Fedora ==
The benefit to Fedora is that users will have access to the most
recent command line tooling for working with Amazon Web Services
features and services. They will have access to new features of the
CLI as well as consistency in the docker and AWS Cloudshell
experiences. That means more consistency in pipeline requirements and
other programmatic access
== Scope ==
* Proposal owners:
Identify the awscli as retired. No additional branches will be built
in support of new releases
* Other developers:
developers will need to review the breaking changes and determine if
they are affected. Issues may require changes to manage pager support
or identify the results encoding where necessary in scripting.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
use of the AWS CLI version 1 in fedora-infra scripts will need to be
tested with the awscli2 prior to the retirement.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
We believe that this is consistent with Community initiatives.
== Upgrade/compatibility impact ==
From the AWS Documentation, the following breaking changes are expected:
* Environment variable added to set text file encoding
* Binary parameters are passed as base64-encoded strings by default
* Improved Amazon S3 handling of file properties and tags for multipart copies
* No automatic retrieval of http:// or https:// URLs for parameters
* Pager used for all output by default
* Timestamp output values are standardized to ISO 8601 format
* Improved handling of CloudFormation deployments that result in no changes
* Changed default behavior for Regional Amazon S3 endpoint for us-east-1 Region
* Changed default behavior for Regional AWS STS endpoints
* ecr get-login removed and replaced with ecr get-login-password
* AWS CLI version 2 support for plugins is changing
* Hidden alias support removed
* The api_versions configuration file setting is not supported
* AWS CLI version 2 uses only Signature v4 to authenticate Amazon S3 requests
* AWS CLI version 2 is more consistent with paging parameters
* AWS CLI version 2 provides more consistent return codes across all commands
== How To Test ==
No special requirements are necessary for testing.
== User Experience ==
The AWS CLI version 2 covers all of the functionality of the version 1
of the AWS CLI. The AWS CLI version 1 is set to be retired in the
future and it would not be beneficial to any of the users to continue
to take dependencies upon it as it is already not the latest version
of the AWS CLI. There are some "breaking" changes from version 1 that
might require you to change your scripts. For a list of breaking
changes in version 2, see
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes....
Breaking changes] in the AWS CLI version 2 User Guide.
== Dependencies ==
No currently known dependencies, but an email was sent to the devel
mailing list to provide more visibility for anyone using it actively.
== Contingency Plan ==
In the event that this version is not retired, both versions will be
maintained. The awscli2 already includes a `Provides: awscli`
directive and that would probably need to be removed to ensure that we
distinguish between the two major releases.
== Documentation ==
The AWS CLI v2 provides a
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html
Migration Guide] for users who are moving from the AWS CLI version 1
'awscli' to the AWS CLI version 2 'awscli2'.
== Release Notes ==
The 'awscli' package has been retired and replaced with the awscli2.
The awscli2 is the most recent major version of the AWS CLI and
supports all of the latest features. Some features introduced in
version 2 are not backported to version 1 and you must upgrade to
access those features. There are some "breaking" changes from version
1 that might require you to change your scripts. For a list of
breaking changes in version 2, see Migrating from AWS CLI version 1 to
version 2.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
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.
== Owner ==
* Name: [[User:Otaylor|Owen Taylor]]
* Email: otaylor(a)redhat.com
== Detailed Description ==
There are two types of Flatpak containers -
runtimes - which contain unmodified Fedora packages,
and applications - which contain Fedora packages rebuilt to relocate
them from /usr to /app.
Currently, the rebuild process is done using modules -
packages are either rebuilt in a shared flatpak-common module, or in a
module specific to the application.
This change replaces this with a separate build target that all
rebuilds are done in.
=== Rebuilding RPMs ===
For each Fedora release, we'll have two additional targets
f39-flatpak-runtime (inherits f39), tags: f39-flatpak-runtime-build,
f39-flatpak-runtime
f39-app (inherits f39-flatpak-runtime), tags: f39-app-build, f39-app
The f39-flatpak-runtime target has a limited use -
it's used to build packages that go into the Flatpak runtimes
(standard and KDE).
This would include flatpak-runtime-config, flatpak-rpm-macros,
but also rebuilds of standard packages if needed to prune dependencies:
currently this is done for gstreamer-plugins-good.
The f39-app target is the main target that is used for prefix=/app rebuilds.
flatpak-rpm-macros is part of the build group for this target,
resulting in builds that target /app.
As currently, spec files can be conditionalized with '%if 0%{?flatpak}'
Builds in f39-flatpak-runtime and f39-app have the dist tags
.f39runtime and .f39app respectively.
This is necessary so that we can automatically rebuild a package
without having to bump the release in the specfile.
(Koji requires everything to have a unique NVR.)
It also allows humans and tools to easily distinguish these specialized builds.
Any Fedora packager can rebuild a package into f39-app using 'fepdkg
build --target=f39-app'.
There will also be a new convenience subcommands of fedpkg 'fedpkg
build-flatpak-rpms',
'fedpkg build-flatpak-rpms-local' that can be used to rebuild all
missing bundled dependencies of a Flatpak,
in Koji or locally.
Once a package exists in f39-app or f38-app, then
[[https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync
distrobuildsync]] will be used to do a build into f39-app each time a
standard build completes.
=== Container Versioning ===
Currently, the version is based on the module version:
firefox:stable:3820230427145713:b1edb643 =>
firefox-stable-3820230427145713.b1edb643
Where the module version is created from platform versions and git
commit timestamps
for the module repository.
We could reproduce something very much like this based on the runtime branch and
git commit timestamp, but since application Flatpaks have an
identifiable "Main RPM"
(unlike the general case of modules and containers), a better scheme is:
firefox-112.0.2-1.fc38 => firefox-flatpak-112.0.2-1
name: main RPM name + -flatpak
version: main RPM version
release: automatically incremented based on existing Koji builds
Because upgrades are done on Flatpak ID (org.mozilla.Firefox),
there is no compatibility impact of switching Flatpaks from 'firefox'
to 'firefox-flatpak'.
There is considerable implementation complexity within OSBS to implement this,
because the N/V/R need to be written into generated Dockerfile as
labels ''before'' building it,
but it should be manageable. If not, we'll need to switch to a different scheme.
(Running dnf with <code>--best</code> when building the container will
help make this reliable
and would be a general improvement.)
=== Updates ===
The current plan is that builds of RPMs will be tagged directly into f39-app and
containers will be composed from the contents of f39-app with no
involvement of Bodhi.
Bodhi is only involved in releasing the container.
We can add CI checks on container updates to compare the rebuilt
packages in the container
to the latest released versions for Fedora, though it's not always
easy to distinguish:
* Newer because of a RPM change that hasn't passed testing yet
* vs. Newer because a spec file was needed to get the package to
rebuild with prefix=/app
Since Fedora does not embargo builds,
there's no potential information leak if a change to dist-git is
released via container before it is released by RPM.
=== Disadvantages and issues===
In moving to this system, we lose the ability to take advantage of the
capabilities of modularity -
to use a different stream branch of a library for an application than
the one shipped in F39, say.
There are essentially no examples of this being used in all the
Flatpaks created for Fedora over the last 5 years,
probably because modularity has gained little traction within Fedora
more broadly.
Some Flatpak modules strip down bundled packages by setting macros in
the buildopts/rpms/macros section of the
modulemd file. For example, flatpak-common has:
buildopts:
rpms:
macros: |
%_without_mingw 1
%_without_tkinter 1
This is no longer possible, so these changes need to be fed back into
spec files with
'%if 0%{?flatpak}' style conditionalization.
Additionally a couple of packages (evolution-data-services and
tracker-miners) are set up so they can be
built with an application-specific D-Bus prefix. Evolution has:
buildopts:
rpms:
macros: |
%_eds_dbus_services_prefix org.gnome.Evolution
This will need to be redone so that evolution-data-services doesn't
need recompilation
and the prefixing can be done by changing configuration files at
container build time.
== Feedback ==
== Benefit to Fedora ==
The experience for Fedora developers who want to create Flatpaks of
their applications will be improved:
* They no longer need to understand modularity and modulemd files -
instead of a modulemd file *and* a container.yaml, they simply create
a container.yaml.
* Rebuilds are automatically shared between Flatpaks, without having
to get them added to the flatpak-common module.
* Because the local build experience is no longer using the poorly
maintained local-build mode of MBS, it can be more efficient and
easier to understand.
This should result in more Fedora Flatpaks and more up-to-date Fedora Flatpaks.
We also greatly reduce the usage of Module Build Service within Fedora.
This is important because upstream maintenance is currently reduced,
and it's not clear that we'll be able to sustain a deployment indefinitely.
== Scope ==
* Proposal owners:
** Update flatpak-module-tools to be able to work without modularity
** Create changes to fedpkg to add 'rebuild-flatpak-packages'
(implementation likely within flatpak-module-tools)
** Update atomic-reactor to be able to build Flatpaks without modularity
* Other developers:
** Flatpaks will need to be migrated to the new system by Flatpak
packagers. While we could make the new system opt-in for F39, it's
probably easiest to just require all Flatpaks to be moved over. In
many cases, this should consist of just a few minor changes to
container.yaml.
** Changes to fedpkg and atomic-reactor need to be reviewed, and for
atomic-reactor deployed. '''Note''' Fedora is on OSBS 1, which is not
a current release. Backporting changes to OSBS 1 seems more realistic
than upgrading Fedora to OSBS 2 at this point.
* Release engineering: [https://pagure.io/releng/issue/11415 #Releng
issue number]
** Release engineering will need to manually create the tags/targets
for F39 and update the tag maintenance scripts to do this for future
releases.
* Policies and guidelines:
https://docs.fedoraproject.org/en-US/flatpak/ will need to be updated
once we have an initial implementation. No impact to packaging
guidelines is expected.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: No
== Upgrade/compatibility impact ==
The Flatpaks built will look exactly the same as before from a user perspective.
== How To Test ==
Testing here will be done by selecting a few Flatpaks and trying to
rebuild them using the new system,
first locally and then on infrastructure.
The final validation will be when we mass rebuild Flatpaks for F39.
== User Experience ==
This should be largely invisible to users.
Hopefully, by simplifying the developer experience around creating Flatpaks,
more Fedora Flatpaks will be available and they will be kept more up-to-date.
== Dependencies ==
This is unrelated to other Fedora changes or to changes within packages.
== Contingency Plan ==
* Contingency mechanism: The current infrastructure for module-based
builds will be maintained, so that if we can't get this done for F39,
we'll build Flatpaks as modules for F39.
* Contingency deadline: By 2023-08-01 we should have runtimes built
and a number of applications or we'll plan on using modules for F39
Flatpaks.
* Blocks release? No
== Documentation ==
At the moment, this change proposal is standalone documentation of the
change. As noted above, https://docs.fedoraproject.org/en-US/flatpak/
will need to be updated once we have an initial implementation. If you
are interested in getting involved in planning and implementing this
change, please contact the
[https://fedoraproject.org/wiki/SIGs/Flatpak Flatpak SIG] matrix room.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
