Wiki -> https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.16
This is a proposed Change for Fedora Linux.
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 ==
ibus-anthy will update the Japanese era for 2024.
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
* ibus-anthy will convert the Japanese era and "2024" mutually
== Feedback ==
== Benefit to Fedora ==
This change will enhance the usability in Japanese.
== Scope ==
* Proposal owners: ibus-anthy
* Other developers:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test ==
# Enable ibus-anthy
# Run gnome-text-editor
# Select the Dictionary mode to Era on IBus panel menu.
# Type "2024" or "れいわ6" and space keys
# The Japanese era and 2024 is converted mutually
== User Experience ==
Users can use the latest Japanese era.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the change to ibus-anthy.
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/Fedora_IoT_Unified_Core
This is a proposed Change for Fedora Linux.
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.
= Build Fedora IoT using rpm-ostree unified core =
== Summary ==
Upstream rpm-ostree development is now focused on "unified core" mode,
with plans to deprecate the previous mode in the future. Fedora IoT is
the last rpm-ostree based Fedora edition using this older, soon to be
deprecated mode with SilverBlue and Kinoite making the change in
Fedora 39. This change will align IoT with the other ostree-based
editions in Fedora.
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]], [[User:idiez| Irene Diez]]
* Email: pwhalen(a)fedoraproject.org, idiez(a)redhat.com
== Detailed Description ==
To learn about the differences between unified core and the previous
mode, please read the upstream
[https://github.com/coreos/rpm-ostree/issues/729 issue]. The main
advantage is that it is stricter and safer, while enabling some post
processing steps to happen during or after the image build. In
addition, unified core support is required for bootupd integration in
Fedora IoT and to align with other rpm-ostree editions in Fedora.
Related changes (already complete):
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
== Feedback ==
== Benefit to Fedora ==
The previous mode in rpm-ostree is not maintained anymore, less tested
and thus prone to bugs. Moving to unified core will align IoT with
what is used to build Fedora CoreOS, SilverBlue and Kinoite as well as
benefit from the additional testing those editions receive. Making the
change in IoT should also reduce the maintenance burden from the
rpm-ostree project as they will be able to remove the old code.
Unified core makes composes work the same on the server side as the
client side and makes them safer by more strictly confining scriptlet
execution.
== Scope ==
* Proposal owners: Testing with the new mode to ensure there are no regressions.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11815 #11815]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
* There will be no impact to end users, upgrades will work the same as
previous releases
== How To Test ==
* Upgrade to Fedora 40 IoT Edition or deploy a new installation.
== User Experience ==
* There will be no impact to users.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to older non-unified core mode.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/Fedora_IoT_Bootable_Container
This is a proposed Change for Fedora Linux.
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 IoT uses OSTree to provide an OS suitable for Edge and IoT
usecases, Ostree Native Container or Bootable Containers, are a new
and interesting mechanism for both building and delivering OSTree
content. This brings this initiative to Fedora IoT to enable other
means of users consuming Fedora IoT.
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Name: [[User:pwhalen| Paul Whalen]]
* Email: <pbrobinson(a)fedoraproject.org>
* Email: <pwhalen(a)fedoraproject.org>
== Detailed Description ==
Fedora IoT uses OSTree to provide an OS suitable for Edge and IoT
usecases, Ostree Native Container or Bootable Containers, are a new
and interesting mechanism for both building and delivering OSTree
content. This brings this initiative to Fedora IoT to enable other
means of users consuming Fedora IoT.
== Feedback ==
== Benefit to Fedora ==
This benefits Fedora IoT users by being able to use container
technologies in the build pipelines and OS definitions. It allows
users to consume Fedora IoT in different ways that may better suit
their environment and ecosystem allowing wider adoption. This is an
expansion of the technologies available and there is no requirement
for users to change.
This will deliver two bootc containers for Fedora IoT users, firstly a
cut down minimal version for users to use as a base to build their own
vision of Fedora IoT and well as the traditional Fedora IoT user
experience.
== Scope ==
* Proposal owners:
The proposal owners will
** Enable the creation of bootable containers artifacts in pungi
** Work with the osbuild team to ensure artifacts are produced
** Test to ensure the user experience is what's expected
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
There's no direct requirement from release engineering. We may need
some adjustment to the koji-osbuild policy.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
There is no upgrade impact, this is a new means of deployment of
Fedora IoT, existing users and artifacts will continue to work as
usual.
== How To Test ==
There will be new bootc containers published, once they are enabled we
will update documentation on how to use and consume them and ways to
provide feedback.
== User Experience ==
There will be a new user experience available for new deployments of
Fedora IoT as well as for upgrades where users wish to be able to pull
updates via a container registry.
== Dependencies ==
There's some dependencies on in-progress work in osbuild which we are
coordinating with the osbuild team.
== Contingency Plan ==
The contingency plan is to delay shipping OSTree bootable containers
if we run into issues with producing them.
== Documentation ==
The Fedora IoT docs will be updated as part of this change.
== Release Notes ==
TBD.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/Deprecate_ntlm_in_cyrus_sasl
This is a proposed Change for Fedora Linux.
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 ==
NTLM has been deprecated for years and is obsolete. Support for it
should be removed as a SASL mechanism. This is no longer supported by
cyrus-sasl upstream. The cyrus-sasl-ntlm subpackage should be removed.
== Owner ==
* Name: [[User:rcritten| Rob Crittenden]]
* Email: rcritten(a)redhat.com.
== Detailed Description ==
NTLM authentication is a family of authentication protocols to
authenticate users and computers. It has been supplanted by more
secure protocols (e.g. Kerberos).
[https://specopssoft.com/blog/microsoft-phases-out-ntlm-with-kerberos/
Microsoft is removing support for NTLM in favor of Kerberos in Windows
to boost security]
[https://en.wikipedia.org/wiki/NTLM#Availability_and_use_of_NTLM Since
2010, Microsoft no longer recommends NTLM in applications:]
Implementers should be aware that NTLM does not support any recent
cryptographic methods, such as AES or SHA-256. It uses cyclic
redundancy checks (CRC) or MD5 for integrity, and RC4 for encryption.
Deriving a key from a password is as specified in RFC1320 and
FIPS46-2. Therefore, applications are generally advised not to use
NTLM.
== Feedback ==
== Benefit to Fedora ==
The cyrus-sasl project dropped support for the ntlm plugin in July,
2023. This proposal removes an unsupported and insecure protocol.
Without upstream support from upstream this plugin is potentially a
heavy burden for Fedora packagers and a risk to security.
== Scope ==
* Proposal owners:
Proposal owner: Deprecate cyrus-sasl-ntlm. This will allow for
sub-package from the distribution in a future release.
* Other developers:
** There do not appear to be any packages that rely on cyrus-sasl-ntlm
* Release engineering:
Some coordination may be necessary so the subpackage never appears in
a given Fedora release. Ideally it is removed in rawhide before the
Fedora-next fork.
* Policies and guidelines: Release notes will be needed to announce
the deprecation and removal.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Existing users of cyrus-sasl-ntlm will need to authenticate using a
different mechanism.
== How To Test ==
This will only affect a narrow set of users. It will be an exercise
for the end-user to determine which mechanism(s) may be a suitable
replacement.
== User Experience ==
This will not be visible to users that aren't using cyrus-sasl-ntml.
It will be '''very''' visible to those that are as they will have to
revise their authentication configuration in order to upgrade or
install the cyrus-sasl package.
== Dependencies ==
None.
== Contingency Plan ==
The proposal involves removing a subpackage from the spec file. There
backup plan is to not do it.
== Documentation ==
This was removed in upstream PR
https://github.com/cyrusimap/cyrus-sasl/issues/708
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild
This is a proposed Change for Fedora Linux.
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 ==
Build the Arm minimal image to be built using osbuild.
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: <pbrobinson(a)fedoraproject.org>
== Detailed Description ==
The Fedora Arm Minimal image is widely used as a base for various
usecases from low level board bring up right through to the basis of
other images. Over time the existing ImageFactory build process has
stagnated limiting our ability to enhance this image. The osbuild team
have worked with the Arm SIG to enable a number of enhancements around
things like Arm SystemReady and other such functionality to improve
this image creation process and to make it easier to use these images
with a much wider range of Arm devices making it easier to bring up
new types of Arm device in Fedora. In the future we are planning
further enhancements to ensure it's easy for developers and users to
make use of the Fedora within the Arm ecosystem.
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The Fedora arm Minimal Image currently requires a number of changes
and hacks to be used on specific devices or SoCs, the move to osbuild
will reduce or entirely eliminate these hacks right away with further
enhancements coming in the future.
== Scope ==
* Proposal owners:
The proposal owners will:
** Enable the creation of Minimal image using osbuild in pungi
** Test the available artifacts
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Changes to the pungi config to use osbuild for minimal image will be
submitted as a PR by feature owners.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No upgrade impact. Only for new users.
== How To Test ==
There will be a new Minimal Image, it will be testable in the same way
as the old image. Test various SoCs with arm-image-installer to ensure
devices boot and run as expected.
== User Experience ==
There should be no change to the user experience for existing users.
We will enable the wider use of
== Dependencies ==
All changes are already in osbuild but we will work with the osbuild
team if any issues arise.
== Contingency Plan ==
The contingency plan is to build the Arm minimal image in the same way
we currently do.
== Documentation ==
There should be no changes required to documentation for existing
users, docs will be updated for specific devices where enhancements
have been made.
== Release Notes ==
TBD.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hello Folks,
I hope this email finds you well. I am writing to inform you about a
slight adjustment in our schedule for the upcoming mass rebuild which
was planned to happen on Jan 17, 2024. As per the discussion in our
releng weekly call today, due to an unexpected delay in merging the
side tag covering the update for the latest GCC version, we find it
necessary to postpone the mass rebuild by one day.
The relevant FESCo ticket addressing this matter can be found at the
following link: Ticket #3145[1]. As a result of this postponement, we
will be holding off on the mass rebuild until the side tag is
successfully merged, and the Bodhi update is created. This decision is
crucial to ensure the smooth integration of the latest GCC version
into the Fedora ecosystem.
Thanks for understanding. We will keep you updated on any further
developments regarding the mass rebuild schedule.
Best regards,
Samyak Jain
Fedora Release Engineering
[1] https://pagure.io/fesco/issue/3145
Wiki -> https://fedoraproject.org/wiki/Changes/Replace_iotop_with_iotop-c
This is a proposed Change for Fedora Linux.
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 ==
Replace (obsolete) iotop with iotop-c
== Owner ==
* Name: [[User:mhlavink| Michal Hlavinka]]
* Email: mhlavink[at]redhat[dot]com
* Name: [[User:bbonev | Boian Bonev]]
* Email: bbonev1[at]ipacct[dot]com
== Detailed Description ==
iotop's upstream does not seem to be active much. Latest version is 0.6
that was released 10 years ago. There were some commits once a while
after that, but not much.
There is better maintained iotop-c implementation that was originally
created for embedded systems. It has small
footprint being written in C and not in python. It is a drop in
replacement. It's actively developed, has good history of resolving
issues, has more features, improved UI (yet almost the same look) and
uses the same command line arguments.
In short, we (iotop and iotop-c maintainers) have decided to replace
iotop with iotop-c. iotop-c will provide iotop (name) and iotop binary
and obsolete original iotop. If there are no issues found, original
iotop will be orphaned.
== Feedback ==
== Benefit to Fedora ==
iotop-c implementation has smaller footprint, more features, polished
UI, uses same command line arguments and has active upstream that has
history of quickly resolving issues.
== Scope ==
* Proposal owners:
1) update iotop-c spec file to obsolete iotop, provide iotop name and
provide iotop binary
2) orphan iotop
* Other developers: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test ==
A) before change happens - just install iotop-c and give it a try
B) after change happens
install iotop, check that you have iotop-c version installed and it works
you can also check that iotop (if installed previously) is
automatically replaced by iotop-c during update
== User Experience ==
iotop-c has slightly different UI look, more polished. It also
consumes less resources.
== Dependencies ==
none
== Contingency Plan ==
Worst case scenario, we can easily revert the change, but we don't
expect any issues as iotop-c isn't that new. It is already present in
current Fedora releases as well as other Linux distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/ROCm6Release
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 AMD ROCm™ 6.0 is the latest release of AMD’s software optimized
for AI and HPC workload performance on AMD GPU’s. This latest release
enables the newest flagship datacenter GPU the AMD Instinct™ MI300 as
well as continuing the GPUs enabled in their last 5.x release,
most/all of their recent GPUs.
== Owner ==
The owners of this change are the HC SIG
(https://fedoraproject.org/wiki/SIGs/HC)
* Name: [[User:trix| Tom Rix]]
* Email: trix(a)redhat.com
== Detailed Description ==
The benefits for frogs include: ROCm 6 has expanded support for AMD
Instinct™ MI300A and MI300X. It includes highly optimized attention
algorithms, and proven collective communications libraries, as well as
optimized performance for FP8 support in PyTorch and hipblasLT. It
includes prepackaged HPC and AI/ML frameworks with streamlined and
improved tools from AMD Infinity Hub.
== Feedback ==
There has been positive feedback from the community for the ease of
using and developing GPU accelerated applications within Fedora.
Because of the interest in AI, the community has requested that ROCm
support be added to PyTorch and other AI applications and frameworks.
To address this feedback several packages are in the process of being
added to Fedora including
rocFFT
rocSolver
hipBLASLt
MiOpen
== Benefit to Fedora ==
Fedora has finally end-to-end open source GPU acceleration. The GPU
hardware driver is in the linux kernel. The compiler is the system
clang. The ROCm software stack provides the higher level libraries
that enable other Fedora packages and user applications to be built
entirely with Fedora.
== Scope ==
* Proposal owners:
The feature owners accomplished packaging the new version of ROCm 6
for Fedora. This provides basic accelerated functionally that should
be used by any package that can take advantage of it.
* Other developers:
If your package or application used the older version of ROCm 5.7.1 or
older, you must verify that you can use the new version of ROCm, 6.0
is a major version change.
The ROCm packages are known to build in Rawhide, no additional effort
is required.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
Yes, it aligns with the current Fedora Community Initiatives.
== Upgrade/compatibility impact ==
No hardware was dropped.
== How To Test ==
Installation instructions can be found here
(https://fedoraproject.org/wiki/SIGs/HC#Installation)
This is by and large a system library change and not directly visible
to the user.
== Dependencies ==
The basic work has been completed.
== Contingency Plan ==
The basic work has been completed.
== Documentation ==
Documentation can be found here (https://rocm.docs.amd.com/en/latest/)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney