F40 Change Proposal: Replace iotop with iotop-c (Self-Contained)
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 -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: ROCm 6 Release (Self-Contained)
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: t...@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 -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Pytorch Release (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/PytorchRelese 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 == This change will bring the first iteration of PyTorch to Fedora. == Owner == This project is owned by the https://fedoraproject.org/wiki/SIGs/PyTorch. * Name: [[User:trix| Tom Rix]] * Email: t...@redhat.com == Detailed Description == The goal of packaging PyTorch for Fedora is to make this open-source machine learning framework easily accessible and seamlessly integrable within the Fedora Linux ecosystem. By providing PyTorch as a packaged software in the Fedora repositories, users gain simplified installation and maintenance processes. This enhances the accessibility of PyTorch for Fedora users, fostering a conducive environment for developers, researchers, and enthusiasts to leverage the capabilities of this powerful machine learning framework. Additionally, packaging PyTorch for Fedora contributes to the broader open-source community by promoting collaborative development and innovation in the field of machine learning on the Fedora platform. == Feedback == The PyTorch SIG meets bi weekly, contributing to the meeting is the best way to engage with what is happening. TBD: Add how to join. The feedback so far has been positive with some high level feature requests. GPU Acceleration More packages that use PyTorch Improving base PyTorch == Benefit to Fedora == This change will introduce PyTorch, a high demand machine learning framework, to Fedora. PyTorch is widely used for tasks such as image and speech recognition, natural language processing, and other artificial intelligence applications, providing a user-friendly interface for building and experimenting with complex machine learning models. This is for CPU (x86_64 and aarch64) only and is the first release for Fedora. The current development effort is focused on AMD GPU acceleration. == Scope == * Proposal owners: This change does not affect other parts of the distribution and is an isolated change. * Other developers: To install use > dnf install python-torch * 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 Community Initiatives: Yes == Upgrade/compatibility impact == This is the first time this package has been available. == How To Test == The PyTorch code base is very large, start with the public examples described here https://pytorch.org/tutorials/beginner/pytorch_with_examples.html == User Experience == How the user installs PyTorch changes from > pip install torch To > dnf install python-torch The pip install requires local building which may fail and will not be consistent from machine to machine. Dnf will always succeed and be consistent. == Dependencies == PyTorch is available for Rawhide. == Contingency Plan == * Contingency mechanism: PyTorch is available for Rawhide. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == There is a wealth of online and print documentation available. A good place to start is the main project page https://pytorch.org/ == Release Notes == PyTorch 2.1.2 and some supporting packages are available in F40 -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change proposal: Bpfman as default eBPF manager (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/DefaultBpfman This is a *proposed* Change for Fedora Linux. This document represents a proposed Change. As part of the [Changes process](https://docs.fedoraproject.org/en-US/program_management/changes_policy/), 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 == bpfman: An eBPF Manager bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. Its notable features encompass: * System Overview: Provides insights into how eBPF is utilized in your system. * eBPF Program Loader: Includes a built-in program loader that supports program cooperation for XDP and TC programs, as well as deployment of eBPF programs from OCI images. * eBPF Filesystem Management: Manages the eBPF filesystem, facilitating the deployment of eBPF applications without requiring additional privileges. We do aim to have this included in Fedora so it becomes the de-facto and easy way to load eBPF programs. == Owner == * Name: [[User:dmellado| Daniel Mellado]] * Email: dmell...@fedoraproject.org * Name: [[davetucker| Dave Tucker]] * Email: datuc...@redhat.com * Name: [[tohojo| Toke Høiland-Jørgensen]] * Email: thoil...@redhat.com == Detailed Description == bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. bpfman is a software stack that aims to make it easy to load, unload, modify and monitor eBPF programs whether on a single host, or in a Kubernetes cluster. bpfman includes the following core components: * bpfman: A system daemon that supports loading, unloading, modifying and monitoring of eBPF programs exposed over a gRPC API. * eBPF CRDS: bpfman provides a set of CRDs (XdpProgram, TcProgram, etc.) that provide a way to express intent to load eBPF programs as well as a bpfman generated CRD (BpfProgram) used to represent the runtime state of loaded programs. * bpfman-agent: The agent runs in a container in the bpfman daemonset and ensures that the requested eBPF programs for a given node are in the desired state. * bpfman-operator: An operator, built using Operator SDK, that manages the installation and lifecycle of bpfman-agent and the CRDs in a Kubernetes cluster. bpfman is developed in Rust and built on top of Aya, a Rust eBPF library. == Feedback = N/A == Benefit to Fedora == bpfman is a software stack simplifying the management of eBPF programs in Kubernetes clusters or on individual hosts. It comprises a system daemon (bpfman), eBPF Custom Resource Definitions (CRDs), an agent (bpfman-agent), and an operator (bpfman-operator). Developed in Rust on the Aya library, bpfman offers improved security, visibility, multi-program support, and enhanced productivity for developers. For Fedora, integrating bpfman would streamline eBPF program loading. It enhances security by restricting privileges to the controlled bpfman daemon, simplifies deployment in Kubernetes clusters, and offers improved visibility into running eBPF programs. This integration aligns with Fedora's commitment to providing efficient and secure solutions, making it easier for users to leverage the benefits of eBPF in their systems. == Scope == * Proposal owners:Submit / review pull-requests and packages to Fedora * Other developers: https://copr.fedorainfracloud.org/coprs/g/ebpf-sig/bpfman-next/ migrate these packages from copr to Fedora alongside proposal owners * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == N/A == How To Test == N/A == User Experience == Users would be able to easily load eBPF programs within Fedora in a way more simpler way than currently using bpfman. == 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), No == Documentation == * https://bpfman.io/main/ == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Run Anaconda dir/image installations only in non-interactive text mode (Self-Contained
Wiki -> https://fedoraproject.org/wiki/Changes/Anaconda_dir_and_image_installations_in_automated_text_mode == Summary == Anaconda will require a fully defined kickstart file for installations into an image or a directory and these installations will run only in a non-interactive text-based user interface. == Owner == * Name: [[User:vponcova| Vendula Poncova]] * Email: * Package: anaconda * Name: [[User:bcl| Brian C. Lane]] * Email: * Package: lorax (livemedia-creator) == Detailed Description == The Anaconda installer supports installations into a local image (via the --image cmdline option) or a local directory (via the --dirinstall cmdline option, the directory is usually a mount point of a custom image). These types of installations are supported by two user interfaces (text-based and GTK-based) in fully interactive, partially interactive and non-interactive modes. We believe that there is no strong reason for all these options, so we would like to minimize the scope of this functionality and support only the text-based non-interactive mode (specifically the command-line mode). It means that Anaconda will require a fully defined kickstart file and run only in the text-based user interface (during dir and image installations). == Feedback == == Benefit to Fedora == This is a preliminary step for an eventual deprecation and removal of the Anaconda support for dir and image installations. This functionality is being slowly taken over by [https://www.osbuild.org/ Image Builder] that is explicitly designed for building images and provides a much broader and better support for all kinds of images. Limiting the scope of dir and image installations in Anaconda will allow its developers to focus their resources on more prospective areas. == Scope == * Proposal owners: Will submit a pull request for [https://anaconda-installer.readthedocs.io/en/latest/ anaconda] to run dir and image installations only in the non-interactive text mode and update [https://weldr.io/lorax/livemedia-creator.html livemedia-creator] to reflect these changes if necessary. * Other developers: No impact. * Release engineering: No impact. There should be zero impact on building official Fedora images since these processes are fully automated and use fully defined kickstart files. [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 Community Initiatives: == Upgrade/compatibility impact == == How To Test == == User Experience == It will be still possible to use anaconda and livemedia-creator for installations into a local image or a directory with a fully defined kickstart file. Users can notice the following changes: * If a user requests a dir or image installation, the installer runs in the text mode. * If the user doesn't specify a kickstart file, the installer will report an error and abort. * If the specified kickstart file is incomplete, the installer will report an error and abort. * All options for specifying the user interface will be ignored (for example, --graphical) == 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 == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
