We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window.
We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window.
We will be migrating a number of our database servers to RHEL9, newer versions of database software and more resources. During the migration services that use these databases may be offline completely. The small servers ( db-fas01 and db03 ) should move and have service restored sooner than the two larger hosts …
We will be upgrading our production OpenShift cluster that runs many of our applications. Normally, this would just be a 0 downtime event, but in this case we are switching networking models, so we need to completely reboot all the nodes, causing some applications to be unavailable for short time …
git rebase HEAD~4 --exec 'git commit --amend --author "Adam Young admiyo@os.amperecomputing.com" --no-edit'
I'm trying to get back to blogging, and to make it regular occurrence in my work week, I thought I'd write a weekly work update.
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.
We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 06 May – 10 May 2024
<figure class="wp-block-image size-full is-style-default"></figure>The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.
The post Infra and RelEng Update – Week 19 2024 appeared first on Fedora Community Blog.
Fedora CoreOS is an automatically updating, immutable operating system built on the trusted Fedora Linux distribution. It allows containerized workloads to run securely and at scale. It combines the benefits of containerization with the reliability and security of an immutable infrastructure. In this article, we’ll explore the unique capabilities of Fedora CoreOS and its use cases.
One of the core principles of Fedora CoreOS is immutability. In traditional operating systems, individual packages are updated. In Fedora CoreOS, updates are applied atomically as a complete replacement of the entire OS. This approach ensures consistency and reliability across deployments. It also eliminates potential drift or configuration issues caused by incremental updates.
Fedora CoreOS leverages Ignition configuration files for automated provisioning and configuration of instances during the initial boot process. However, instead of manually creating these JSON-formatted Ignition files, you can write the configurations in a simpler, human-readable, YAML based format called Butane config. Butane files are then converted into the corresponding Ignition files using the Butane tool.
By automating the provisioning process with Ignition configs generated from Butane specifications, you can consistently deploy and configure Fedora CoreOS instances across different environments. These configuration files ensure repeatable and reliable deployments. The instances apply the configuration defined in the Ignition config on the first boot.
This automation capability is particularly valuable for infrastructure components use cases that require high availability and minimal downtime. These may include systems such as load balancers, firewalls, and other critical systems.
Fedora CoreOS is optimized for running containerized workloads and seamlessly integrates with container orchestration platforms like Kubernetes. It comes pre-installed with both Podman and Moby-engine (Docker) for all your container needs.
Fedora CoreOS is also at the core of OKD, the community distribution of Kubernetes. It is built from the same projects as Red Hat OpenShift. Additionally, you can customize Fedora CoreOS for specific workloads or environments. This makes it particularly useful for setting up dedicated Kubernetes clusters for different applications or environments.
One notable example is Typhoon. A free and open-source project that provides declarative Kubernetes infrastructure management and integrates with Fedora CoreOS. With Typhoon, you can define your desired Kubernetes cluster configuration using human-readable language. And it will provision and configure additional cluster components, including Fedora CoreOS machines serving as worker nodes. This integration enables efficient and flexible Kubernetes deployments tailored to your needs. It ensures consistent and repeatable configurations across diverse environments like bare metal, cloud providers, and local networks.
While Fedora CoreOS is immutable, it is still customizable for specific workloads or environments. This capability enables you to optimize Fedora CoreOS instances for particular applications or use cases by adding necessary packages, configurations, or services.
By tailoring Fedora CoreOS to your workloads, you can strike a balance between the benefits of an immutable operating system and the flexibility to meet your requirements. This approach ensures that your applications run in a consistent and optimized environment while still leveraging the security and reliability advantages of CoreOS.
Fedora CoreOS follows a structured release cycle. Update releases typically occur every two weeks after undergoing extensive testing and validation through multiple update streams, such as “testing” and “next”. This automatic update mechanism ensures that Fedora CoreOS instances stay up-to-date with the latest stable releases. This mechanism also minimizes security risks and provides access to new features and enhancements.
You can opt to run instances on these testing streams to automatically evaluate upcoming releases before deploying to production. This way, you can identify and mitigate potential issues or incompatibilities. If an update introduces problems or vulnerabilities, the ability to roll back to a previous version further enhances the resilience of Fedora CoreOS-based infrastructure.
While Fedora CoreOS is optimized for running containerized workloads and Kubernetes clusters, it is also designed to be operable as a standalone, general-purpose server operating system. This versatility makes it a compelling choice for a wide range of server workloads, beyond just containerized applications or Kubernetes clusters. It can provide benefits such as improved security, reliability, and reduced maintenance overhead, even for traditional server applications.
As an open-source project, Fedora CoreOS serves as a valuable resource for exploration and learning about immutable operating systems, containerization, and modern infrastructure practices. The Fedora CoreOS rich documentation includes articles like “Getting Started with Fedora CoreOS” and a host of other useful information about Fedora CoreOS. The Fedora CoreOS FAQ provides a solid starting point for understanding and experimenting with Fedora CoreOS. If you are new to Fedora CoreOS, the tutorial section is a great place to start. For further information about ignition files and how they are made from butane files, check out this section of the Fedora CoreOS documentation.
Additionally, the open-source nature of Fedora CoreOS fosters community collaboration and contribution, enabling knowledge sharing and collective advancement of the project. This inclusive ecosystem encourages users to explore, learn, and contribute to its development, further enhancing its capabilities and adoption.
Fedora CoreOS offers a powerful combination of immutability, automatic updates, container optimization, and customization capabilities. All of this makes it a versatile choice for modern infrastructure and application deployment scenarios. Fedora CoreOS provides a robust foundation to meet diverse needs. Whether you’re deploying containerized applications, setting up Kubernetes clusters, exploring edge computing or IoT, or building secure and resilient infrastructure.
By embracing the principles of immutable infrastructure, automated deployments, and containerization, you can unlock the full potential of Fedora CoreOS and drive innovation in your organization’s infrastructure and application delivery pipelines.
Developing long running tasks might be my least favorite coding activity. I love writing and debugging code…I’d be crazy to be in this profession if I did not. But when a task takes long enough, your attention wanders and you get out of the zone.
Building the Linux Kernel takes time. Even checking the Linux Kernel out of git takes a non-trivial amount of time. The Ansible work I did back in the OpenStack days to build and tear down environments took a good bit of time as well. How do I keep from getting out of the zone while coding on these? It is hard, but here are some techniques.
Build processes necessarily need a lot of tools. On a Fedora System, I often start by doing
yum groupinstall "Development Tools"
And then still may need to install a few more things: Java, Rust, or Python libraries, meson, Dwarves, bison, and others.
If you are doing CI inside a container, as is the norm for the git hosting services, you can specify a custom container. Anything that is not part of your build should be in the container.
Note that by doing this, you are putting another variable in your build process: which version of the container was used. By installing packages at build time, you are using the latest. By using a pre-built container, some of those packages may have gone stale. This is kind of the reason FOR using containers, as you can change package versions at your own cadence, but make sure you are deliberate about it.
If part of a long running task works, hold on to the output of that task, and disable the task itself. This implies that any information generated from this stage of the task can be deduced from the artifacts.
A Linux Kernel build takes a long time, even with all 100+ processors working on it. Skip the build until you need it to be fresh again.
If you are doing a git checkout, but don’;t actually need that checkout for the follow on stage, you can short circuit that checkout by doing a mkdir of the root directory. This is a more useful hack than I originally realized. Pulling down a huge tree like the Linux kernel can take quite some time. Skipping it until you are ready to test it can save that time.
If your automation is primarily for moving artifacts around, you can temporarily skip the stage that builds the artifacts until you get the follow on stages working. This is often done in conjunction with the git checkout skip above.
There are many variations to these work-arounds, as well as several more I have not yet documented. The point is to identify where you are waiting on tasks, and to figure out ways to avoid that time while developing the rest of your automation.
If you are working with Ansible, using the flag to start on a specific task can be a powerful time saver. However, that means structuring your playbook such that you don’t gather up all the information you need for a task at the beginning.
The same general idea is true for bash based operations: you can use functions that you call directly, but make sure you don;’t need too much context for that function call. Make it easy to start in the middle, and end in the middle.
The May syslog-ng newsletter is now on-line:
The syslog-ng Administration Guide received a new look and easier navigation. Not only that, but it is also up-to-date now. Besides, there are now contributor guides available both for the documentation and for syslog-ng developers.
The admin guide is available at: https://syslog-ng.github.io/admin-guide/README
You can reach all syslog-ng OSE-related documentation at: https://syslog-ng.github.io/
If you find any issues, pull requests and problem reports are welcome. The contributor guide describes how you can fix / extend the documentation. You can report issues at: https://github.com/syslog-ng/syslog-ng.github.io/issues
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-05-documentation-grouping-by-pam-essentials-health
<figure><figcaption>TLDR: Thanks to José Exposito, libwacom 2.12 will support all [1] Huion and Gaomon devices when running on a 6.10 kernel.
libwacom, now almost 13 years old, is a C library that provides a bunch of static information about graphics tablets that is not otherwise available by looking at the kernel device. Basically, it's a set of APIs in the form of libwacom_get_num_buttons and so on. This is used by various components to be more precise about initializing devices, even though libwacom itself has no effect on whether the device works. It's only a library for historical reasons [2], if I were to rewrite it today, I'd probably ship libwacom as a set of static json or XML files with a specific schema.
Here are a few examples on how this information is used: libinput uses libwacom to query information about tablet tools.The kernel event node always supports tilt but the individual tool that is currently in proximity may not. libinput can get the tool ID from the kernel, query libwacom and then initialize the tool struct correctly so the compositor and Wayland clients will get the right information. GNOME Settings uses libwacom's information to e.g. detect if a tablet is built-in or an external display (to show you the "Map to Monitor" button or not, if builtin), GNOME's mutter uses the SVGs provided by libwacom to show you an OSD where you can assign keystrokes to the buttons. All these features require that the tablet is supported by libwacom.
Huion and Gamon devices [3] were not well supported by libwacom because they re-use USB ids, i.e. different tablets from seemingly different manufacturers have the same vendor and product ID. This is understandable, the 16-bit product id only allows for 65535 different devices and if you're a company that thinks about more than just the current quarterly earnings you realise that if you release a few devices every year (let's say 5-7), you may run out of product IDs in about 10000 years. Need to think ahead! So between the 140 Huion and Gaomon devices we now have in libwacom I only counted 4 different USB ids. Nine years ago we added name matching too to work around this (i.e. the vid/pid/name combo must match) but, lo and behold, we may run out of unique strings before the heat death of the universe so device names are re-used too! [4] Since we had no other information available to userspace this meant that if you plugged in e.g. a Gaomon M106 and it was detected as S620 and given wrong button numbers, a wrong SVG, etc.
A while ago José got himself a tablet and started contributing to DIGIMEND (and upstreaming a bunch of things). At some point we realised that the kernel actually had the information we needed: the firmware version string from the tablet which conveniently gave us the tablet model too. With this kernel patch scheduled for 6.10 this is now exported as the uniq property (HID_UNIQ in the uevent) and that means it's available to userspace. After a bit of rework in libwacom we can now match on the trifecta of vid/pid/uniq or the quadrella of vid/pid/name/uniq. So hooray, for the first time we can actually detect Huion and Gaomon devices correctly.
The second thing Jose did was to extract all model names from the .deb packages Huion and Gaomon provide and auto-generate all libwacom descriptions for all supported devices. Which meant, in one pull request we added around 130 devices. Nice!
As said above, this requires the future kernel 6.10 but you can apply the patches to your current kernel if you want. If you do have one of the newly added devices, please verify the .tablet file for your device and let us know so we can remove the "this is autogenerated" warnings and fix any issues with the file. Some of the new files may now take precedence over the old hand-added ones so over time we'll likely have to merge them. But meanwhile, for a brief moment in time, things may actually work.
[1] fsvo of all but should be all current and past ones provided they were supported by Huions driver
[2] anecdote: in 2011 Jason Gerecke from Wacom and I sat down to and decided on a generic tablet handling library independent of the xf86-input-wacom driver. libwacom was supposed to be that library but it never turned into more than a static description library, libinput is now what our original libwacom idea was.
[3] and XP Pen and UCLogic but we don't yet have a fix for those at the time of writing
[4] names like "HUION PenTablet Pen"...
As much as I try to be a “real” programmer, the reality is that we need automation, and setting up automation is a grind. A necessary grind.
One thing that I found frustrating was that, in order to test our automation, I needed to kick off a pipeline in our git server (gitlab, but the logic holds for others) even though the majority of the heavy lifting was done in a single bash script.
In order to get to the point where we could run that script in a gitlab runner, we needed to install a bunch of packages (Dwarves, Make, and so forth) as well as do some SSH Key provisioning in order to copy the artifacts off to a server. The gitlab-ci.yml file ended up being a couple doze lines long, and all those lines were bash commands.
So I pulled the lines out of gitlab-ci.yml and put them into the somewhat intuitively named file workflow.sh. Now my gitlab-ci.yml file is basically a one liner that calls workflow.sh.
But I also made it so workflow.sh can be called from the bash command line of a new machine. This is the key part. By doing this, I am creating automation that the rest of my team can use without relying on gitlab. Since the automation will be run from gitlab, no one can check in a change that breaks the CI, but they can make changes that will make life easier for them on the remote systems.
The next step is to start breaking apart the workflow into separate pipelines, due to CI requirements. To do this, I do three things:
The reason for the last split is to keep logic from creeping into the pipeline functions. They are merely interfaces to the single set of logic in functions.sh.
The goal of having the separate functions source-able is to be able to run interior steps of the overall processing without having to run the end-to-end work. This is to save the sitting-around time for waiting for a long running process to complete….more on that in a future article.
As described in Fedora Strategy 2028: April 2024 Update, we came out of our annual face-to-face meeting with a new presentation for our strategy for the next five years. That article gave the background — this is the high-level strategy itself.
We’re going to double the number of contributors who are active every week.
Our goal is to ensure that Fedora is healthy and sustainable. As a project, we’re generally in great shape. However: there are many areas where everyone feels under-resourced, and we have too many places where we have a very poor “yak farm factor” — if one or two people are ready for a change and go off to start new lives, will the areas they’re working in collapse? Plus, there’s always so much more exciting new stuff that we could be doing, and maybe need to do to remain relevant as the computing landscape changes.
We can measure aspects of this in many different ways: interconnectedness, onboarding, burnout, team resilience, and so many more. But, the weekly-active-contributor number gives us a simple, basic check. If that number is going up, we must be doing something right.
The metric itself isn’t the goal in itself.. We don’t want to merely inflate a number, after all. So, we also plan to watch those other community health metrics, and we’ll adjust as needed to make sure that the Guiding Star is really leading us to the right path.
This means different things to different people and is often different across projects. However, for this purpose, we’re using a broad definition.
A Fedora Project contributor is anyone who:
Fedora has numerous already-public data sources for activity, and we plan to use those as widely as possible. Unlike smaller projects, we can’t simply count commits in a git repo — and, I think that’s a good thing, because in order to get a meaningful number, we need to count more than just code and other technical contributions.
Upcoming posts:
The post Fedora Strategy 2028: High-Level View appeared first on Fedora Community Blog.
We are happy to announce the general availability of Fedora Asahi Remix 40. This release brings the newly released Fedora Linux 40 to Apple Silicon Macs.
Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. It was unveiled at Flock 2023 and first released later in December with Fedora Asahi Remix 39.
In addition to all the exciting improvements brought by Fedora Linux 40, Fedora Asahi Remix brings conformant OpenGL 4.6 support to Apple Silicon. It also continues to provide extensive device support, including high quality audio out of the box.
Fedora Asahi Remix offers KDE Plasma 6 as our flagship desktop experience. It also features a custom Calamares-based initial setup wizard. A GNOME variant is also available, featuring GNOME 46, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.
You can install Fedora Asahi Remix today by following our installation guide. Existing systems, running Fedora Asahi Remix 39, can be updated following the usual Fedora upgrade process.
Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.
For quite a while now, we’ve had image-based Fedora Linux variants—starting with Fedora Atomic Host and Atomic Desktop. The original variants evolved into Fedora CoreOS, Fedora IoT, a whole family of Fedora Atomic Desktops, and the awesome Universal Blue project. Bootable containers make it much simpler to create and collaborate on image-based Fedora systems. Here’s how you can get involved.
If you’ve used one of these image-based Fedora systems, you know how easy they are to update, upgrade, or, if things aren’t working quite right, to roll back. However, creating your own custom image-based Fedora system has always been a bit tricky, requiring special tools, processes and infrastructure.
Over the past couple of years, the tools and methods available for building image-based systems in Fedora have evolved. They now natively support OCI/Docker containers as a transport and delivery mechanism for operating system content.
With these changes, and the introduction of bootc, we now have the tools to build image-based systems using ordinary Containerfiles and regular OCI-container build tools. We also have the infrastructure to define, build, deploy and manage Linux systems.
For instance, the Fedora IoT WG has plans to deliver two bootc containers for Fedora IoT users. There is a cut down minimal version for users to use as a base to build their own vision of Fedora IoT. There is also a second image to deliver the traditional Fedora IoT user experience.
We have a great opportunity to enhance collaboration among image-based Fedora variants, and to empower other projects and individual users to create their own Fedora-based derivatives by working together on bootable container technologies.
That’s why I’m excited to announce that we’ve proposed a new Fedora Community Initiative to seize this opportunity. This initiative aims to bring together the Fedora working groups that build and promote image-based Fedora variants.
The contributors working on the proposed initiative will:
Check out the initiative wiki page for more information. You can learn who to reach out to if you’d like to get involved in the effort, in the context of one of the Fedora variants. You can also join the discussion on Fedora’s matrix instance in the fedora-bootc room, or on Fedora discussion by following or posting with the bootc-initiative tag. Finally, check out this doc page to kick the tires on Fedora bootc for yourself.
After the hard work of pushing out the Fedora Linux 40 release, we now look at celebrating with a release party! The Fedora 40 Release Party will take place on May 24-25, Friday and Saturday.
Fedora Release Parties are virtual, user-focused conferences where the community comes together to talk about what’s new in the latest release of Fedora and where we’re going for future releases. Topics we’ve covered include the process of working through implementing a change and roadmaps for what different teams want to do next in Fedora. Sometimes there are updates from Fedora-associated groups who have something to share, like Amazon or Lenovo. We also have breaks for socials where we can talk to each other in video calls (you don’t have to share video or speak if you don’t want to). If you have an interest in a behind-the-scenes look at your favorite distro, come learn and hang out with the contributors who make it!
In previous years we used Hopin to run virtual conferences, but the Fedora 40 Release Party will be the first that we do in Matrix! We’ve wanted to do this since the Creative Freedom Summit showed how it could be done a couple of years ago. This is a step that allows us to lean more on open source for outreach.
However, we also want to be open in another way, and that’s with livestreaming. We will be streaming the talks on our Fedora Project YouTube channel. That way anyone can watch and the streams will be immediately available afterwards!
Details for registering will come soon, but for now please save the date for May 24-25!
We hope to see you there!
Check out the Fedora 39 Release Party to get an idea of the kinds of topics we cover.
Get hyped on social media with hashtag #FedoraReleaseParty!
PACKIT_PROJECT_VERSION
environment variable.
(packit#2297)status_name_template
option that allows you to configure
status name for a Packit job. For further details have a look at our
docs.
This feature is still experimental and at the moment it is not possible
to retry such jobs via GitHub Checks' re-run.
(packit-service#2402)Josh and Kurt talk about a sudo replacement going into systemd called run0. It sounds like it’ll get a lot right, but systemd is a pretty big attack surface and not everyone is a fan. We shall have to see if this ends up replacing sudo.
<audio class="wp-audio-shortcode" controls="controls" id="audio-3377-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_427_Will_run0_replace_sudo.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_427_Will_run0_replace_sudo.mp3</audio>We're happy to announce Kiwi TCMS version 13.2!
IMPORTANT: This is a small release which contains several improvements, internal refactoring and updated translations!
Recommended upgrade path:
13.1.1 -> 13.2
You can explore everything at https://public.tenant.kiwitcms.org!
---
Upstream container images (x86_64):
kiwitcms/kiwi latest 6cb7c6d669a2 681MB
IMPORTANT: version tagged and multi-arch container images are available only to subscribers!
quay.io/kiwitcms/version 13.2 (aarch64) e596cef147cc 04 May 2024 693MB quay.io/kiwitcms/version 13.2 (x86_64) 6cb7c6d669a2 04 May 2024 681MB quay.io/kiwitcms/enterprise 13.2-mt (aarch64) ab6d8f2039b4 04 May 2024 1.06GB quay.io/kiwitcms/enterprise 13.2-mt (x86_64) a6938623851d 04 May 2024 1.04GB
IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!
Applies to any digital property under *.tenant.kiwitcms.org!
Backup first! Then follow the Upgrading instructions from our documentation.
Happy testing!
---
If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!
Did you forget the -r
when cloning a git repo with submodules? The command you’re looking for is git submodule update --init
We are happy to announce that GNOME was assigned eight slots for Google Summer of Code projects this year!
GSoC is a program focused on bringing new contributors into open source software development. A number of long term GNOME developers are former GSoC interns, making the program a very valuable entry point for new members in our project.
In 2024 we will mentoring the following projects:
As part of the contributor’s acceptance into GSoC they are expected to actively participate in the Community Bonding period (May 1 – 26). The Community Bonding period is intended to help prepare contributors to start contributing at full speed starting May 27.
The new contributors will soon get their blogs added to Planet GNOME making it easy for the GNOME community to get to know them and the projects that they will be working on.
We would like to also thank our mentors for supporting GSoC and helping new contributors enter our project.
If you have any doubts, feel free to reply to this Discourse topic or message us privately at soc-admins@gnome.org
Hello Fedorans! The F40 election campaign is now in full swing, and this cycle will be running a little differently than the previous F39, F38, etc. We are welcoming the EPEL Steering Committee to our elections cycle and having our Council elections move to once per year too. Read on for the details
During the Fedora Council’s hackfest in February this year, the Council discussed administrative items, including the timing of the Fedora Council elections. It was unanimously agreed that the elections move to a once-per-year cadence, rather than every six months. The reason being that having a member exit and a new one enter the council every six months has become a little disruptive, and stabilizing the term to a continuous 12-month period would be more beneficial to not only the council members, but the project itself, with the Council having some continuity. This also makes travel planning for the annual Council hackfest easier.
So to start this off, the F40 election will be the only election for the Fedora Council this year, and going forward, the Council will hold its election after the Spring/Summer release.
Important Election Information
Another exciting update to our elections circuit is the addition of the EPEL Steering Committee elections campaign! The EPEL Steering Committee elections will now be run by the Fedora Operations Architect and will be held once per year, after the Spring/Summer release of Fedora Linux. You can nominate yourself, or someone else (with their consent), by visiting the nominations page and adding your name in the nominations box at the end. Interview questions are being finalized and will be available to candidates very soon.
Our F40 elections schedule is currently viewable here and all elections – Council (x2 seats), FESCo (x4 seats), Mindshare (x1 seat) and EPEL (x4 seats), will follow this schedule. Nominations have begun on April 24th so if you or someone you know would be a great asset to one of these governance bodies, consider nominating yourself or them (with their consent of course) before the nomination period closes on May 8th!
The post F40 Elections: Nominations now open & welcoming EPEL appeared first on Fedora Community Blog.
In this video Jeff Geerling accounced that “Corporate Open Source is Dead”. He already dropped support from his really good ansible playbooks. This was because Red Hat only distributes its sources to customers. Another brick in this wall was announced today by the great ELrepo project.
In this blogpost it was announced that RHEL made some changes in the upcoming 8.10 and 9.4 releases of RHEL and this will break some of the kernel modules that were created by elrepo to allow running RHEL with older cards – that are not official supported anymore. The fun thing is not the whole driver that was deprecated, but only some of the supported pci-id where removed.
Especially for home lab users this created a big problem. aacraid, megaraid_sas, mlx4 and mpt3sas are drivers that are used in a lot of home labs everywhere.
Again the overall intention from Red Hat are not the problem. If Red Hat would break support of that in RHEL 10 there would be no problems. It would be interesting to know if this is a unexpected consequence of an patch or a targeted business decision. Yes I know why the support was dropped by Red Hat, but Red Hat is not only forgetting it roots, but again kicked the non-prod users in the curb. Just after they droped Centos and broke there promis there as well.
At least for my homelab this creates an extra work to do, because my RAID Controller is on the deprecated list. At least AlmaLinux has undo this patch and you don’t even need elrepo to support his older hardware.
I was planning to reinstall the host anyway. I only have to decide to select Fedora or AlmaLinux. The time to decide that is coming earlier the I hoped.
We are happy to announce the Fedora Week of Diversity (FWD) 2024 from June 17th to 22nd, organized by the Fedora DEI Team. FWD is a time when we come together to honor the diverse voices, perspectives, and skills that enrich the vibrant Fedora community.
Every year, FWD serves as a platform to spotlight the different members and their noteworthy contributions to the community and projects they work on. This year’s theme, “Empowering Diversity, Enriching Communities,” acknowledges the views, perspectives, and talents of individuals from different backgrounds, experiences, and walks of life, impacting not only our community but also extending across the entire open-source ecosystem.
FWD runs from June 17th to 22nd, 2024, featuring a series of interviews with community members sharing their Fedora stories. Additionally, we will host a virtual event on June 21st – 22nd, featuring talks, panel discussions and social activities. FWD will showcase highlights from this content to emphasize Fedora’s diversity.
By participating in FWD, you can contribute to creating an open-source community where everyone is empowered to succeed and make a difference.
As part of FWD, we are opening Call for Proposals (CFP) to invite community members to share their insights, experiences, and expertise on topics related to diversity, equity, and inclusion in open source. This year’s theme for FWD is “Empowering Diversity, Enriching Communities.” We aim to explore how diversity in perspectives, backgrounds, and experiences strengthens our open-source community and fosters innovation. Don’t forget to apply by May 11.
During Fedora Week of Diversity, we’ll be publishing Contributor Stories from our vibrant Fedora community members. Dive into CommBlog to explore their unique journeys with Fedora and join us in celebrating their valuable contributions to the world of open source.
Would you like to assist with specific tasks related to FWD? Check our repository to learn more about our workflow and add a comment on the issue you want to help out with.
Let’s celebrate our differences together, amplify the voice of those underrepresented, and stand shoulder to shoulder, united in our commitment to diversity, equity, and inclusion. Join us for Fedora Week of Diversity 2024, and together, let’s create a future where everyone’s voice is heard, their contributions valued, and every individual has the opportunity to succeed. If you have any questions, ping us on Matrix.
The post Join Fedora Week of Diversity (FWD) 2024 appeared first on Fedora Community Blog.
تیم توسعه پروژه ی فدورا خبر انتشار نسخه نهایی Fedora Linux 40 را اعلام کرد. این نسخه از فدورا نیز مانند سایر نسخه های پیشین شامل تغییرات و ويژگی های جدیدی می باشد.
در زمینه ی تغییرات برای میزکارها می توان به استفاده از میزکار Gnome 46 در نسخه ی Fedora workstation 40 اشاره کرد و همچنین استفاده کردن از KDE Plasma 6 در نسخه Fedora KDE
از دیگر تغییراتی مهمی که به چشم می خورد در زمینه ی توسعه هوش مصنوعی (AI development) و استفاده از بسته ی PyTorch می باشد.
PyTorch یک فریمورک (framework) محبوب برای deep learning است و نصب مطمئن آن با نسخه های مناسب درایورها و کتابخانه ها و غیره می تواند دشوار باشد. بسته فعلی فقط از اجرا بر روی CPU، بدون شتاب دهنده GPU یا NPU پشتیبانی می کند، اما این فقط اولین مرحله است زیرا هدف تولید یک پشته کامل با PyTorch و سایر ابزارهای محبوب آماده برای استفاده در انواع سخت افزارها است.
مانند همیشه جهت دانلود نسخه های مختلف لینوکس فدورا ۴۰ می توانید به سایت رسمی آن مراجعه کنید:
https://fedoraproject.org/
The post نسخه نهایی لینوکس فدورا ۴۰ منتشر شد first appeared on طرفداران فدورا.
Fedora 40 has been released! So let’s see what comes in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic and Budgie Atomic).
As you might have guessed from the title, we are now called Fedora Atomic Desktops! See the Introducing Fedora Atomic Desktops Fedora Magazine article for all the details.
The summary is that the Fedora Atomic Desktops are made up of four atomic spins:
And we have a landing page on fedoraproject.org.
Unfortunately, we could not land bootupd support in this release due to an issue found late in Anaconda’s handling of bootupd installations which relied on incomplete functionality in bootupd.
We will attempt to add bootupd again after the release, via an update.
If you encounter Secure Boot errors or need to update your bootloader in the meantime, you can try the instructions from fedora-silverblue#543. Make sure to have a Live USB ready in case you encounter an issue. Please make backups beforehand.
We are hoping to land improvements to bootupd that should simplify this process.
See: atomic-desktops-sig#1.
Fedora Silverblue comes with the latest GNOME 46 release.
For more details about the changes that comes with GNOME 46, see What’s new in Fedora Workstation 40 on the Fedora Magazine and Fedora Workstation 40 – what are we working on from Christian F.K. Schaller.
GNOME Software will no longer overlay the langpack packages for your locale on the first update. This should make updates much faster as they won’t need to overlay packages anymore (unless you explicitly decide to overlay some packages).
If you are updating from a previous release, you will have to remove this overlayed package manually. For example:
1. Find the overlayed package using rpm-ostree status:
$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
Version: 40.20240410.1 (2024-04-10T03:43:23Z)
Commit: 2428fdbec13787633b3bcd79d4f002ab48582bae8c6a473ca357a1ad43573a94
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
LayeredPackages: langpacks-fr
fedora:fedora/40/x86_64/silverblue
Version: 40.20240402.0 (2024-04-02T00:39:43Z)
Commit: 634c8097165e6aab2baeaca6ae6d1ea2a7f11fba9f4955297bcf0fc2507047be
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
LayeredPackages: langpacks-fr
2. Remove the overlayed package and reboot:
$ rpm-ostree uninstall langpacks-fr
...
Note that this will remove the dictionaries for the corresponding language from your system and thus for applications included in the image.
For Flatpaks, the dictionaries are downloaded according to the languages set in the Flatpak config. If you have set your preferred languages in GNOME Settings, this configuration should have been set already. For example:
# Get the current config
$ flatpak config --list
languages: en;fr;de (default: en)
extra-languages: *unset*
# Set the languages to use
$ flatpak config --set languages "en;fr"
See the flatpak-config documentation for more details.
Also note that with this change the translated man pages for system commands will also be removed. To get the man pages back, you can install them in a container using toolbox for example:
$ toolbox create
$ toolbox enter
$ sudo dnf install man-pages-fr
See: atomic-desktops-sig#14.
Fedora Kinoite ships with Plasma 6, Frameworks 6 and Gear 24.02 (Fedora Change). See also What’s New in Fedora KDE 40? on the Fedora Magazine.
Fedora Kinoite is now Wayland only. Legacy X11 applications will run using XWayland. See Fedora 40: X11 is now unsupported.
If you have an NVIDIA GPU and encounter issues, I recommend looking at Universal Blue images (see below), waiting for an upcoming NVIDIA driver update that will hopefully improve Wayland support or trying out the updated Nouveau / NVK stack for supported cards.
A subset of KDE Apps are now installed by default as Fedora Flatpaks by Ananconda for new installations. The Flatpaks are not installed on updates but you can install them from the Fedora Flatpak remote or from Flathub.
Most KDE Apps are directly published and maintained on Flathub by the KDE community and we have mostly completed the transition to the Qt 6.6 and KDE Framework 6 Runtime.
You can track the progress for the remaining apps in kde/teams/flathub#26.
Fedora Sway Atmoic comes with the latest 1.9 Sway release.
Fedora Budgie Atomic ships with the latest release of the Budgie Desktop 10.9 “release series”. Budgie 10.9 features some initial porting work to libxfce4windowing as it progresses towards its move to Wayland and redesigns its Bluetooth applet with new direct (dis-)connect functionality.
Additionally, Fedora Budgie Atomic ships with the latest Budgie Control Center and takes into use budgie-session. As Buddies of Budgie officially supports Fedora, Budgie Desktop has also received numerous backported bug fixes to provide Fedora users an even better experience.
You can learn more about the latest happenings in Budgie on the Buddies of Budgie blog.
Unfortunately, this section will be short this time, as there has not been much progress on our future plans since the last time.
We will provide an updated article when more information becomes available.
Our friends in the Universal Blue, Bluefin and Bazzite projects also released updates for their images.
Universal Blue is now considered Generally Available alongside Bluefin.
For all your gaming needs, Bazzite reached version 3.0, rebasing on our fresh Fedora 40 images.
They are also introducing Aurora, a KDE Plasma and Kinoite based alternative to Bluefin. See the Introduction to Aurora post for all the details.
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.
koji_build
job has a new sidetag_group
option that allows to perform a downstream Koji build in a sidetag.
A new sidetag will be created for each configured dist_git_branch
if it doesn't already exist.
This represents the first step towards multi-package Bodhi updates. Stay tuned for further advancements!
(packit-service#2409)copr_build
job status checks were sometimes wrongly updated with a misleading
message after a SRPM build failure. (packit-service#2406)Josh and Kurt talk about a paper describing using a LLM to automatically create exploits for CVEs. The idea is probably already happening in many spaces such as pen testing and intelligence services. We can’t keep up with the number of vulnerabilities we have, there’s no way we can possibly keep up with a glut of LLM generated vulnerabilities. We really need to rethink how we handle vulnerabilities.
<audio class="wp-audio-shortcode" controls="controls" id="audio-3372-2" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_426_Automatically_exploiting_CVEs_with_AI.mp3?_=2" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_426_Automatically_exploiting_CVEs_with_AI.mp3</audio>Fedora 40 has been released! 🎉 So let’s see what comes in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic and Onyx Atomic).
Note: You can also read this post on the Fedora Magazine.
As you might have guessed from the title, we are now called Fedora Atomic Desktops! See the Introducing Fedora Atomic Desktops Fedora Magazine article for all the details.
The summary is that the Fedora Atomic Desktops are made up of four atomic spins:
And we have a landing page on fedoraproject.org.
Unfortunately, we could not land bootupd support in this release due to an issue found late in Anaconda’s handling of bootupd installations which relied on incomplete functionality in bootupd.
We will attempt to add bootupd again after the release, via an update.
If you encounter Secure Boot errors or need to update your bootloader in the meantime, you can try the instructions from fedora-silverblue#543. Make sure to have a Live USB ready in case you encounter an issue. Please make backups beforehand.
We are hoping to land improvements to bootupd that should simplify this process.
See: atomic-desktops-sig#1.
Fedora Silverblue comes with the latest GNOME 46 release.
For more details about the changes that comes with GNOME 46, see What’s new in Fedora Workstation 40 on the Fedora Magazine and Fedora Workstation 40 – what are we working on from Christian F.K. Schaller.
GNOME Software will no longer overlay the langpack packages for your locale on the first update. This should make updates much faster as they won’t need to overlay packages anymore (unless you explicitly decide to overlay some packages).
If you are updating from a previous release, you will have to remove this overlayed package manually. For example:
rpm-ostree status
:$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
Version: 40.20240410.1 (2024-04-10T03:43:23Z)
Commit: 2428fdbec13787633b3bcd79d4f002ab48582bae8c6a473ca357a1ad43573a94
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
LayeredPackages: langpacks-fr
fedora:fedora/40/x86_64/silverblue
Version: 40.20240402.0 (2024-04-02T00:39:43Z)
Commit: 634c8097165e6aab2baeaca6ae6d1ea2a7f11fba9f4955297bcf0fc2507047be
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
LayeredPackages: langpacks-fr
</figure>
$ rpm-ostree uninstall langpacks-fr
...
</figure>
Note that this will remove the dictionaries for the corresponding language from your system and thus for applications included in the image.
For Flatpaks, the dictionaries are downloaded according to the languages set in the Flatpak config. If you have set your preferred languages in GNOME Settings, this configuration should have been set already. For example:
<figure class="highlight"># Get the current config
$ flatpak config --list
languages: en;fr;de (default: en)
extra-languages: *unset*
# Set the languages to use
$ flatpak config --set languages "en;fr"
</figure>
See the flatpak-config documentation for more details.
This will also remove the translated man pages for system commands. To get the man pages back, you can install them in a container using toolbox for example:
<figure class="highlight">$ toolbox create
$ toolbox enter
$ sudo dnf install man-pages-fr
</figure>
See: atomic-desktops-sig#14.
Fedora Kinoite ships with Plasma 6, Frameworks 6 and Gear 24.02 (Fedora Change). See also What’s New in Fedora KDE 40? on the Fedora Magazine.
Fedora Kinoite is now Wayland only. Legacy X11 applications will run using XWayland. See Fedora 40: X11 is now unsupported.
If you have a NVIDIA GPU and encounter issues, I recommend looking at Universal Blue images, waiting for an upcoming NVIDIA driver update that will hopefully improve Wayland support or trying out the updated Nouveau / NVK stack for supported cards.
A subset of KDE Apps are now installed by default as Fedora Flatpaks by Ananconda for new installations. The Flatpaks are not installed on updates but you can install them from the Fedora Flatpak remote or from Flathub.
Most KDE Apps are directly published and maintained on Flathub by the KDE community and we have mostly completed the transition to the Qt 6.6 / KDE Framework 6 Runtime.
You can track the progress for the remaining apps in kde/teams/flathub#26.
Fedora Sway Atmoic comes with the latest 1.9 Sway release.
Fedora Budgie Atomic ships with the latest release of the
Budgie Desktop 10.9
“release series”. Budgie 10.9 features some initial porting work to
libxfce4windowing
as it progresses towards its move to Wayland and redesigns
its Bluetooth applet with new direct (dis-)connect functionality.
Additionally, Fedora Budgie Atomic ships with the latest Budgie Control Center and takes into use budgie-session. As Buddies of Budgie officially supports Fedora, Budgie Desktop has also received numerous backported bug fixes to provide Fedora users an even better experience.
You can learn more about the latest happenings in Budgie on the Buddies of Budgie blog.
Unfortunately, this section will be short this time, as there has not been much progress on our future plans since the last time.
We will provide an updated article when more information becomes available.
Our friends in the Universal Blue, Bluefin and Bazzite projects also released updates for their images.
Universal Blue is now considered Generally Available alongside Bluefin.
For all your gaming needs, Bazzite reached version 3.0, rebasing on our fresh Fedora 40 images.
They are also introducing Aurora, a KDE Plasma and Kinoite based alternative to Bluefin. See the Introduction to Aurora post for all the details.
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.
I hope you are all enjoying F40 and for some information on a few upcoming important stuff ‘n’ things in Fedora, read on
If you have not already submitted a talk/workshop/whatever you have been thinking about doing to the Flock to Fedora cfp, you are in luck – submission closes tomorrow, April 29th so you have one more day to get that great idea of yours into us.
Flock to Fedora is set for August 7th – 10th in Rochester, NY, USA. Check out the website for more details on our annual contributors conference.
The Fedora Linux 40 elections cycle has now begun, and our nominations period is open! You can nominate yourself, or someone you think would be a great fit (with their permission of course), to the Fedora Council, Fedora Mindshare Committee, Fedora Engineering Steering Committee or the EPEL Steering Committee until May 8th.
To nominate yourself or someone else, you just need to visit the nominations page of whichever group you would like to be elected to and fill out your name and FAS ID in the nominations box at the end. A set of interview questions will then be shared with each candidate after the nominations period closes for them to answer, which will be published on the community blog a few weeks before voting opens.
This term, the following seats are open:
For more information on the elections process in Fedora, visit our docs site and for other key dates, you can view the elections schedule too.
Development is now underway (and has been for a while) on Fedora Linux 41 and our release schedule is live. Here are some dates you should keep in mind if you have any changes you would like to propose for F41:
If you are unsure of how to propose a change, there is some excellent documentation and video tutorial to help, and you can always reach out directly to me too.
Below are some recently announced changes for F41 and feedback is most welcome:
There is a lot of conversations happening around Fedora, and it can be hard to keep track of them all! Below is the top two on my own list from both discussion.fpo and devel@lists.fedoraproject.org, in case you need some inspiration
Did you know there is a weekly hack-athon on the Fedora Infra apps happening? Aurélien Bompard hosts a weekly stream on twitch every Friday (that hes available) where he goes through bugfixes. Turn on notifications to Aurélien’s topic thread on discourse and catch him on twitch on Fridays!
As always, package reviews are needed and welcome and if you would like to adopt any packages that have been orphaned, you can find the full list from the most recent email, or visit the packager dashboard here.
The post Fedora Ops Architect Weekly appeared first on Fedora Community Blog.
En ce mardi 23 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 40.
Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.
Cette 40e édition propose principalement une mise à jour de son interface principale GNOME 46 et de son concurrent KDE Plasma 6 qui passe à Wayland par défaut au passage.
Passage à GNOME 46. Cette version se démarque par beaucoup d'améliorations pour son navigateur de fichiers nommé Fichiers. Il dispose dorénavant, en plus d'une recherche dans le dossier et sous-dossiers en cours, d'une recherche globale utilisable via le bouton dédié avec une icône de loupe ou par le raccourci clavier Ctrl+Shift+F
(contrairement à la recherche locale qui se fait via le raccourci Ctrl+F
). Il permet de chercher dans l'ensemble du répertoire utilisateur voire davantage selon les préférences de l'utilisateur.
L'icône de loupe prend place où était l'icône de progression lors des opérations sur les fichiers comme les décompressions ou la copie de fichiers. De fait ces opérations sont affichées en bas de la barre latérale ce qui permet d'afficher plus d'informations en un coup d’œil. L'application bénéficie en outre d'améliorations de performances en particulier pour afficher de gros dossiers avec des images ou lors du passage d'une vue liste à une vue par icônes et vice-versa. Plus de périphériques sur le réseau peuvent être découverts automatiquement permettant notamment de parcourir leurs fichiers.
GNOME prend en charge les comptes Microsoft OneDrive ce qui permet de facilement parcourir les fichiers sauvegardés avec ce service. Dans les comptes à distance, le protocole WebDAV est aussi pris en charge pour l'accès à des calendriers, listes de contacts et autres fichiers partagés. Pour l'authentification de ces comptes en ligne, le navigateur par défaut est utilisé dorénavant ce qui permet d'utiliser une plus grande diversité de moyens d'authentifications comme l'usage de périphériques USB dédiés.
Pour les amateurs de la connexion distante, il est maintenant possible de se connecter à GNOME graphiquement à distance via le protocole RDP. Auparavant seulement une session ouverte pouvait être pilotée ainsi. Cette option est désactivée par défaut et nécessite des droits appropriés, tout se configure via le panneau de configuration tout comme le bureau distant.
En parlant du panneau de configuration, ce dernier a été amélioré en regroupant plusieurs configurations par sections afin d'améliorer la clarté de l'application. La liste des menus devenait particulièrement importante et rendait difficile la localisation des éléments à configurer. De plus, la configuration du pavé tactile a été améliorée pour permettre de choisir entre le clic dans un coin ou le clic à deux doigts pour réaliser l'équivalent d'un clic droit avec ce périphérique.
Côté accessibilité, le lecteur d'écran Orca a été modernisé pour le rendre plus performant, plus fiable et plus compatible avec les applications Wayland ou celles exécutées dans un bac à sable tel que Flatpak. Il est possible de couper temporairement Orca avec le raccourci clavier Ctrl+Alt+Shift+Q
ce qui est particulièrement utile en cas de conflit entre deux lecteurs d'écran ou si une application utilise du son aussi.
Les notifications dans GNOME indiquent par quelle application elles ont été émises. Il est maintenant possible d'étendre facilement la notification afin de pouvoir la visualiser en entier, utilisant une vue plus compacte par défaut.
De manière plus générale, GNOME bénéfice d'améliorations de performances notamment pour son terminal, son moniteur système qui bénéficie aussi d'un graphe dédié aux entrées / sorties sur les espaces de stockage, pour l'enregistrement de l'écran, le visionneur d'images ou encore pour la recherche globale de GNOME. L'ensemble des applications GTK4 bénéficie d'un nouveau moteur de rendu qui améliore le rendu du texte mais aussi les performances.
L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6. Au passage Plasma 6 utilise Wayland par défaut, et s'il était prévu de supprimer totalement la possibilité de l'utiliser avec X11 pour simplifier la maintenance, des volontaires ont permis de repousser l'échéance pour l'instant.
Sous le capot, cette version utilise la nouvelle bibliothèque majeure graphique qu'elle emploie à savoir Qt 6. C'était l'occasion par ailleurs de rationaliser les différentes couches techniques et APIs internes afin de supprimer ce qui n'était plus au goût du jour ou trop peu employé pour être maintenu.
Cette version propose la prise en charge partielle du rendu des couleurs en HDR pour les applications et matériel compatibles, mais aussi un profil de couleur spécifique par écran afin d'avoir un rendu fidèle des couleurs. Dans cette thématique pour les personnes souffrant de daltonisme ou d'autres formes de maladies dichromatiques peuvent utiliser des filtres pour améliorer la lisibilité des applications et de leur contenu.
Dans les changements plus classiques, la barre principale est par défaut en mode flottant comme pour beaucoup de docks d'autres environnement de bureaux ou systèmes d'exploitation. Il est bien sûr possible de changer tout cela dans les paramètres et plus encore concernant cette barre principale. Concernant l'affichage principal, l'effet cube en cas de changement de bureau virtuel est de nouveau disponible. Pour la capture d'écran, il est possible de choisir une zone arbitraire de l'écran, d'utiliser le codec VP9 pour les enregistrements vidéos et de choisir sa qualité.
Le thème par défaut de l'environnement nommé Breeze bénéficie d'un rafraichissement, il utilise moins de cadres et a un affichage un peu plus compact.
Comme pour GNOME, la recherche a bénéficié d'un effort important. En plus de permettre la conversion de fuseaux horaires ou de trier les résultats par type, les performances sont grandement améliorées : jusqu'à 200% plus rapide pour chercher des documents, jusqu'à 60% plus rapide pour trouver une application, le tout jusqu'à moins 30% d'usage du processeur. La recherche obtient les résultats pour les textes traduits dans votre langue ou en anglais pour les noms ou les descriptions d'applications par exemple.
Il est dorénavant possible de s'authentifier par mot de passe ou par empreinte digitale en même temps, il n'est plus nécessaire de forcer l'une des deux options.
Et tant d'autres changements encore.
Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d'AMD. Il concerne notamment les puces AMD Instinct MI300A et MI300X, et fournit de nouveaux algorithmes optimisés du mécanisme d'attention et de bibliothèques de communication. Il permet l'usage de flottant 8 bits pour gagner en consommation mémoire au détriment de la précision du modèle pour PyTorch et hipblasLT. Via la plateforme AMD Infinity Hub, il est possible d'obtenir des paquets prêts à l'usage pour certains travaux en IA ou calculs haute performance notamment pour les calculs scientifiques.
Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet. L'objectif dans cette phase est de pouvoir démarrer sur de tels noyaux directement sans chargeur de démarrage intermédiaire, tout en offrant la possibilité de démarrer sur d'autres noyaux et de passer automatiquement au noyau suivant par défaut suite à une mise à jour. Les machines Aarch64 (ARM 64 bits) peuvent également s'en servir maintenant. Une image pour cette architecture et x86_64 doit également être fournie pour un contexte de virtualisation en étant basée sur ces fichiers kickstart.
Si vous souhaitez tester cela sur un système existant, vous pouvez installer les paquets virt-firmware
, uki-direct
avant d'exécuter le script sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
pour configurer les partitions proprement afin d'être découvrables par le système, puis enfin installer le paquet kernel-uki-virt
pour qu'il installe le noyau proprement avec la nouvelle méthode. Il est préférable de tester cela sur une machine virtuelle ou si vous savez ce que vous faites avec du matériel standard type ahci / nvme pour le stockage principal. Bien sûr ce travail reste expérimental et est réservé à ceux qui savent comment faire pour réparer le système en cas de problèmes.
Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30. Les commandes pour lancer et relancer IBus fonctionnent depuis l'environnement Plasma Wayland dorénavant, et pour cet environnement aussi les préférences sont maintenant accessibles depuis le menu non contextuel.
Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais. Le principal changement est la conversion possible d'ère japonaise avec 2024.
NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection (RFC 5227) avant de l'attribuer à la machine. En somme au moment de s'attribuer une adresse IP donnée, une requête ARP est envoyée au réseau concernant cette adresse. Si une réponse est obtenue, l'adresse est déjà utilisée et n'est donc pas exploitable sans perturber le réseau. Ce mécanisme existe pour les réseaux avec IP fixes ou même avec un serveur DHCP central car rien n'empêche la présence d'une machine configurée avec une IP fixe dans le réseau malgré tout. Si le réseau a un serveur DHCP et qu'un conflit est détecté, la réponse DHCPDECLINE sera envoyée pour obtenir peut être une autre adresse. En cas de conflit une erreur sera rapportée permettant à l'utilisateur de diagnostiquer le problème et d'y apporter une solution. Par défaut le système attendra 200 ms avant de décider qu'il n'y a aucune réponse. Pour l'IPv6 cela est inclus dans le standard RFC 4862 ce qui rend ce changement non nécessaire dans ce cas de figure.
NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. En effet, certains systèmes utilisent l'adresse Mac pour identifier les machines en déplacement de réseau en réseau permettant une pseudo géolocalisation ce qui nuit à la vie privée. Mais la méthode usuelle de changer d'adresse MAC aléatoirement à chaque connexion pose un problème en cas de réseau restreignant l'accès à certaines adresses MAC uniquement ou en changeant d'adresse IP à chaque reconnexion. Cette méthode est un compromis entre le respect de la vie privée et le confort d'utilisation. Cela est fait en ajoutant la configuration wifi.cloned-mac-address="stable-ssid"
dans le nouveau fichier /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf
.
Les entrées des politiques SELinux qui font référence au répertoire /var/run
font maintenant référence au répertoire /run
. Il y a dix ans déjà que le premier répertoire a bougé vers le deuxième chemin mais SELinux a gardé les vieilles règles en utilisant un lien d'équivalence entre eux pour permettre leur utilisation. Cependant certains outils comme restorecon
ne gèrent pas bien cette situation tout comme les administrateurs systèmes qui ne sont pas sûrs de comment écrire proprement de nouvelles règles. Pour résoudre le problème le lien d'équivalence passe de /run = /var/run
à /var/run = /run
.
L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux. Il pouvait exploiter les fichiers /etc/passwd
et /etc/group
via l'utilisation de l'option id_provider=files
. Cependant cette option n'est plus proposée par le projet officiel et n'était à l'époque conservée que pour permettre l'authentification via des cartes à puce ou l'enregistrement de sessions. Mais dans les deux cas il est possible de passer à la méthode proxy via l'option id_provider=proxy
pour le remplacer dans ces cas d'usage. Un guide officiel est proposé pour effectuer la conversion pour ceux qui en ont besoin.
DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets. Jusqu'à présent il le faisait par défaut parmi d'autres métadonnées, mais cette information n'est en réalité nécessaire que dans certains cas précis qui ne concernent pas celui de la majorité des utilisateurs. Notamment pour quelques paquets ayant une dépendance envers un fichier particulier plutôt qu'un paquet donné ou si on cherche un paquet fournissant un fichier spécifique. Cela permet de réduire les ressources consommées chez les utilisateurs mais aussi au sein de l'infrastructure de Fedora car il n'est plus nécessaire de fournir ces données assez conséquentes de manière systématique.
L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares. Ce fichier qui représente environ 1 Mio est téléchargé quotidiennement parfois sur des liaisons coûteuses. Ainsi la pression est réduite sur les infrastructures notamment le CDN fwupd et la bande passante en utilisant localement la ressource quand elle est disponible. Passim utilise avahi pour signaler son service sur le réseau local qui est disponible via le port 27500 afin que les autres clients puissent identifier si des métadonnées sont disponibles localement.
Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage. Par conception les systèmes avec rpm-ostree comme ceux-ci n'ont pas le chargeur de démarrage qui se met à jour par ce biais car cela n'est pas une opération sûre. En effet, la mise à jour de ces systèmes repose sur le principe de transaction pour que le passage d'un état à un autre soit fiable, cependant ce mécanisme ne fonctionne pas bien pour le chargeur de démarrage qui est un composant distinct et critique. On retrouve la même problématique pour les systèmes utilisant un mécanisme de mise à jour basé sur une partition A et B et passant de l'un à l'autre. D'où la création de cet utilitaire qui est mis à disposition pour ceux qui le souhaitent, du moins pour les machines disposant d'un EFI. La mise à jour est pour le moment manuelle à la demande avec la commande bootupctl update
. La mise à jour automatique sera prévue dans le futur.
Le paquet libuser
est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd
est supprimé. La bibliothèque libuser sert à cacher les différences entre les utilisateurs locaux et distants via le protocole LDAP. Mais la prise en charge de ce protocole reste incomplet et il n'y a pas de plan pour aller plus loin, comme sssd
peut la remplacer dans ce rôle, la décision de la supprimer prochainement de Fedora fait sens. Pour l'instant seuls les paquets usermode
et util-linux
en ont encore besoin. Le paquet passwd
quant à lui disparaît pour se débarrasser de la dépendance à libuser. La commande pour changer de mot de passe ne change pas, mais est fournie par le paquet shadow-utils
.
Le paquet cyrus-sasl-ntlm
a été supprimé. Le protocole d'identification NTLM n'est plus maintenu, au profit du protocole Kerberos et ce composant dans SASL n'est plus maintenu depuis des années justifiant une telle décision.
La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM. BerkeleyDB 5.x fourni par Fedora n'est plus à jour ce qui pose des soucis en terme de bogues et de sécurité, d'autant plus avec le rôle de PAM dans le système. La licence de BerkeleyDB a changé dans la branche 6.x, passant de BSD à AGPL rendant impossible l'adoption de cette version plus à jour pour ce composant, les licences n'étant pas compatibles. Ainsi GDBM se pose comme une alternative pour résoudre ce problème. BerkeleyDB 5.x a débuté sa sortie du projet Fedora depuis Fedora 33, ceci est une étape de plus dans cette direction.
Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne. La raison est analogue au paragraphe précédent.
Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0. Le projet abandonne la prise en charge de BerkeleyDB pour sa base de données interne pour la même raison que précédemment. En dehors de cela qui introduit des incompatibilités, cette mise à jour est en réalité assez mineure sur les autres aspects en fournissant essentiellement des correctifs de bogues.
Le paquet iotop
est remplacé par iotop-c
. Si le nom du paquet change, celui du binaire installé ne change pas. iotop n'est plus vraiment maintenu depuis une dizaine d'années et est sévèrement concurrencé par iotop-c sur cet aspect qui bénéfice en plus d'une empreinte mémoire plus petite étant rédigé en C au lieu de Python. Il n'est pas pertinent aux yeux des mainteneurs de maintenir les deux ainsi.
L'orchestrateur de conteneurs Kubernetes évolue de la version 1.27 à la version 1.29. Ce changement est communiqué car Kubernetes déconseille le saut des versions ce que Fedora fait actuellement en passant à la version 1.28 en fournissant ainsi la dernière version disponible. Cette version propose aux utilisateurs la possibilité d'avoir un écart de version de n-2 à n-3 pour les versions mineures entre le nœud principal et le plan de contrôle. Il est également possible si un nœud est indisponible suite à une panne ou à un état non récupérable de démarrer les services qu'il gérait dans un autre nœud dans un état sain. Le mode d'accès aux données ReadWriteOncePod
devient accessible sans restrictions, permettant de restreindre l'accès à des données à un seul pod à la fois plutôt qu'à un seul nœud, pour réduire le risque d'accès concurrents en particulier en écriture. De même le module KMS v2 est disponible à tous pour réaliser les services de chiffrement pour vos APIs.
Par ailleurs les paquets de Kubernetes sont restructurés. L'objectif est de se rapprocher de l'organisation du projet upstream et de simplifier la vie des utilisateurs. Ainsi le paquet kubernetes
récupère l'utilitaire kubelet
qui avait son paquet dédié et les services fournis via l'ancien sous-paquet kubernetes-master
sont renommés kubernetes-systemd
. Les paquets kubernetes-client
et kubernetes-kubeadm
restent inchangés.
Pendant que podman est mis à jour vers la version 5. Cette version abandonne la prise en charge des cgroupv1 du noyau, de même que les plugins CNI ou la base de données clé / valeur Boltdb au profit de SQLite pour les nouvelles instances. Le format des fichiers de configuration pour les podman machines a été profondément remanié, rendant nécessaire la recréation des machines virtuelles concernées conçues avant cette version.
Le paquet wget2
remplace le paquet }}wget}} en fournissant une nouvelle version. Cette version propose du code multithreadé et qui télécharge plus vite grâce à la prise en charge du protocole HTTP2 avec la compression ou le téléchargement parallèle. Il propose plus d'options, il a également plus de tests automatiques pour s'assurer de sa robustesse dans le temps. Sa réécriture dans un style plus moderne devrait faciliter l'adoption de nouveaux protocoles à l'avenir. Par contre les protocoles dépassés WARC et FTP sont moins bien pris en charge. La licence change pour GPLv3+, de même que sa bibliothèque libwget2 vers LGPLv3+.
Le gestionnaire de base de données PostgreSQL migre vers sa 16e version. De part l'arrêt des modules, les paquets pour des versions alternatives sont également réintroduits. Ainsi les paquets postgresql15*
font leur apparition pour la prise en charge de la version précédente, et les paquets postgresql17*
seront proposés quand la 17e version sera disponible. En terme de changements apportés par cette nouvelle version, les jointures FULL
ou OUTER
sur des hash peuvent être parallélisées pour de meilleures performances. Il est dorénavant possible de répliquer des données depuis des serveurs dans un état standby, de même la réplication peut être appliquée en parallèle pour de larges transactions afin d'améliorer les performances de l'opération. La vue pg_stat_io
fournit des informations statistiques concernant les entrées et sorties. SQL/JSON qui est introduit dans le standard SQL bénéficie de constructeurs dédiés pour créer des objets JSON mais aussi des fonctions identités pour connaître le type des clés. Et ce parmi de nombreuses corrections de bogues et d'amélioration de performances.
Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11 pour MariaDB. Le paquet community-mysql
est renommé mysql
tandis que le paquet mariadb
ne fourni plus de binaires avec le nom mysql
. En effet la décision à l'époque a été prise car il semblait convenu que MariaDB remplacerait MySQL tout comme LibreOffice a supplanté OpenOffice.org mais force est de constater que les deux projets vont cohabiter longtemps. Cela rend le tout plus simple pour l'utilisateur. Cependant, puisque ces logiciels évoluent séparément, ils deviennent peu à peu incompatibles et le mainteneur abandonne la possibilité d'utiliser MariaDB comme serveur avec MySQL comme client et vice-versa. Aucune autre distribution en fournissait une telle possibilité et cela devenait difficile à maintenir car cela était source de problèmes.
En terme de nouvelles fonctionnalités pour MariaDB, il est possible de lire entièrement les tables Information Schema Parameters et Information Schema Routines tout en améliorant les performances dans la procédure. Il est possible de savoir combien de temps une requête passe dans l'optimiseur via l'option ANALYZE FORMAT=JSON
. Les semi-jointures pour la mise à jour ou la suppression de données sont optimisées. Les privilèges SUPER
et READ ONLY ADMIN
sont dorénavant distincts, à ce sujet il est possible de fournir à tous les utilisateurs des droits spécifiques via la requête GRANT <privilege> ON <database>.<object> TO PUBLIC
.
Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2,41, glibc 2.39 et gdb 14.1.
Concernant la suite de compilateurs GCC, elle continue l'amélioration de la prise en charge des langages C23 et C23, alors que débute la prise en charge de la future norme C26. De nombreux modèles de puces Aarch64 et x86_64 bénéficient de micro-optimisations, tandis qu'il y a un début de prise en charge des nouvelles instructions pour l'architecture x86_64 d'Intel dénommées APX et AVX10. L'analyseur statique de code peut afficher visuellement les dépassements de tampons pour mieux comprendre ce qui se passe en mémoire.
Pour la suite d'outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64.
Quant à la bibliothèque standard C glibc, cela se traduit par de nombreuses améliorations comme la prise en charge de la pile cachée pour éviter les attaques par modification d'adresse de retour, ce que Fedora Linux active par ailleurs. De même pour limiter certaines attaques, la glibc propose de pouvoir réécrire au lancement la PLT pour obtenir les adresses des fonctions des bibliothèques dynamiques plutôt que de les avoir lors du premier appel à chaque fonction. Le programme démarre plus lentement mais est plus sûr pour la suite. L'en-tête <stdbit.h>
fait son apparition pour les manipulations sur les bits, opérations basées sur la norme de C20. Et une nouvelle fonction posix_spawnattr_setcgroup_np
est ajoutée pour démarrer un processus dans un cgroup donné afin d'éviter des situations de concurrence entre le moment où le processus est démarré et où les restrictions s'appliquent.
Enfin le débogueur gdb propose un début de prise en charge du protocole de Microsoft Debugger Adapter Protocol pour faire le lien entre les débogueurs et des IDEs ou éditeurs de code afin de faciliter leur intégration mutuelle. Il peut également gérer des entiers au delà de 64 bits, de même que d'appeler une commande shell avec l'instruction $_shell
pour obtenir son résultat. Les instructions de l'architecture Aarch64 SME et SME2 commencent à être gérées et l'API Python est considérablement étoffée pour ceux qui veulent scripter le débogueur.
La suite de compilateurs LLVM est mise à jour à la version 18. Fedora en profite pour que CLang utilise des informations de débogage au format DWARF-5 au lieu de DWARF-4 par défaut comme appliqué par le projet amont. Pour simplifier la procédure de compilation de Fedora pour les paquets utilisant cette chaîne de compilation, le Fat-LTO sera employé pour permettre l'usage du LTO quand c'est possible comme cela était déjà le cas avec GCC. Jusqu'alors ces paquets étaient compilés avec LTO par défaut avec une éventuelle conversion vers ELF à la main si la compatibilité le nécessitait ce qui était particulièrement lourd. Par ailleurs les paquets de compatibilité des versions précédentes fournissent les binaires des différents utilitaires et non plus seulement les bibliothèques et en-têtes.
Concernant les nouveautés apportées par le projet en lui même, comme pour la chaîne de compilation GNU, les architectures Aarch64, x86_64 ou RISC-V sont mieux gérées. Le compilateur CLang suit GCC avec du travail sur C20, C23 pour améliorer la compatibilité avec le standard et le début de prise en charge de la future norme C++26.
Mise à jour de la bibliothèque C++ Boost à la version 1.83. Depuis la version 1.81, cette bibliothèque propose un module pour communiquer avec les bases de données MySQL ou encore une bibliothèque Compat:
pour fournir en code compatible C++11 des ajouts proposés par les standards ultérieurs.
Le langage Go passe à la version 1.22. La sémantique de la boucle for évolue un peu avec la création de la variable de boucle à chaque itération de boucle plutôt qu'à la première avec mise à jour à chaque passage. De plus il accepte l'usage des plages de valeurs basées sur des entiers. L'exécution des programmes gagne 1 à 3% grâce à l'optimisation de la localisation mémoire des métadonnées du ramasse miette. Les programmes compilés avec un profil d'optimisation peuvent gagner entre 2 et 14% de performances par rapport à la version précédente grâce à la possibilité d'appliquer la technique sur plus de fonctions qu'avant.
Le JDK de référence pour Java passe de la version 17 à 21. OpenJDK peut maintenant faire du filtrage par motif dans une instruction switch
. Il est possible aussi d'affecter le résultat d'une identification de type dans une variable directement afin de pouvoir s'en servir immédiatement. Des fils d'exécution virtuels font leur apparition qui sont plus légers et performants, plutôt dédiés à des tâches courtes avec beaucoup d'attentes, ces tâches peuvent ainsi bénéficier de meilleure performance notamment en terme de latence. Il introduit également une API pour les collections d'objet en séquence (donc ordonnées). De même une nouvelle API pour manipuler les clés cryptographiques symétriques fait son entrée. Le ramasse miette Z Garbage Collector améliore ses performances.
Ruby 3.3 surveille sa syntaxe avec Prism. Prism est un gem introduisant un nouveau parseur très flexible qui a vocation à remplacer Ripper. Le compilateur juste à temps YJIT bénéficie de nombreuses améliorations comme de meilleures performances, une réduction de la consommation mémoire avec un code généré plus compact et avec moins de métadonnées et un temps de compilation plus court. Un concurrent RJIT fait son entrée, écrit en pur Ruby et non en C comme YJIT, il a plus vocation à servir de terrain d'expérimentation. Le ramasse miette est également plus performant.
Le langage PHP utilise la version 8.3. Cette version permet de définir des classes constantes, il propose également un attribut #\Override
si une classe surcharge une méthode d'une classe parente. Une nouvelle fonction json_validate
permet de vérifier la validité d'un JSON sans le décoder. Le Randomizer
a plus de méthodes pour permettre de générer des noms ou nombres aléatoires suivant les besoins.
La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora. L'objectif est de fournir une meilleure expérience pour les développeurs de ce genre de solution. Un groupe de travail dédié s'est mis en place avec une réunion bi-hebdommadaire. Pour le moment l'architecture x86_64 est la seule prise en charge avec un effort important mis sur les solutions AMD.
Le paquet python-sqlalchemy
utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité. Cette version apporte entre autre de l'annotation de type ce qui permet de construire des ORM sur un modèle déclaratif. Les opérations d'insertions sont aussi bien plus performantes quelque soit le gestionnaire de base de données derrière.
La bibliothèque de validation des données Pydantic utilise dorénavant la version 2. Outre l'amélioration des performances, il change radicalement son API ce qui coupe la compatibilité ascendante.
La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8. De même la compatibilité ascendante n'est pas garantie ce qui a rendu ce portage compliqué.
La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x. Depuis Fedora 36 la branche 3 est employée par défaut dans Fedora. OpenSSL 1.1 n'est plus maintenue depuis fin de l'année dernière ce qui rend sa maintenance délicate et non sûre d'où son abandon malgré la faible compatibilité entre les deux versions pour ceux qui s'en servait encore.
Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant. Ces versions sont plus rapides grâce à l'emploi des instructions plus modernes des processeurs actuels tout en gardant la compatibilité par rapport à l'implémentation de référence.
Le langage Python ne bénéficie plus de la version 3.7. Depuis juin de l'année dernière cette version n'est plus maintenue et il n'y a pas de raison de poursuivre son maintien dans les dépôts en tant que version de compatibilité.
L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji. L'utilitaire ImageFactory employé jusqu'à présent n'est plus maintenu. Les outils mkosi
et osbuild
ont été considérés mais non retenus, le premier car il manque de flexibilité pour fournir toutes les images souhaitées, tandis que le second est certes adopté par l'équipe de Fedora Workstation mais ne semble pas adapté aux besoins des images clouds qui reposent sur d'autres technologies dont rpm-ostree et doit fournir des délivrables plus variés également. En effet l'image cloud cible Vagrant, Azure, AWS, GCP et peut dorénavant viser aussi les images pour WSL2 ou pour conteneurs directement.
Tandis que l'édition Workstation aura son image ISO générée avec l'outil Image Builder. En effet ce dernier bien que déjà employé par Fedora Workstation bénéficie enfin de la prise en charge des images ISO live. Il remplace donc les outils lorax/livemedia-creator qui avaient beaucoup de problèmes. Il devient aussi plus simple pour quiconque de générer son image ISO avec un simple fichier TOML pour le décrire et quelques utilitaires en ligne de commande.
L'image minimale ARM sera construite avec l'outil OSBuild. Comme dans le cadre de l'édition Cloud, il remplace l'utilitaire ImageFactory qui montrait ses limites. L'objectif à terme est de pouvoir supprimer totalement ou partiellement les hacks nécessaires à ce jour pour utiliser cette image sur une grande variété de systèmes ARM.
Fedora IoT bénéficiera d'images pouvant démarrer dans des conteneurs. Ainsi il est possible de tester le système dans des conteneurs plutôt que via de la virtualisation classique ou sur des machines physiques. Cette flexibilité peut aider le test par les utilisateurs mais également par ses mainteneurs.
Il bénéficiera également des images Simplified Provisioning. Fedora IoT peut ainsi utiliser l'utilitaire coreos-installer
pour l'installer sur le disque directement et ce en utilisant un argument noyau pour savoir sur quel disque l'installer. Ainsi pas besoin de fichier kickstart ou d’interaction avec l'utilisateur ce qui simplifie la procédure et son automatisation. Cela s'intègre parfaitement avec les dispositifs Fido Device Onboarding et Ignition pour la configuration de tels systèmes dans un environnement de production.
Et le tout sera construit en utilisant rpm-ostree unified core. L'ancien mode n'est en effet plus maintenu et moins testé. Le mode unifié permet au compose server, qui est l'image de base créée à partir de RPM, de fonctionner de manière similaire au client qui ajoute des commits par dessus pour personnaliser le contenu du système. Cela permet de simplifier la maintenance côté rpm-ostree mais aussi de résoudre certaines difficultés notamment pour la gestion du démarrage avec bootupd, les labels SELinux et l'utilisation de conteneurs pour les scriplets pré et post installations des paquets. Depuis Fedora Linux 39 où Silverblue et Kinoite ont amorcé la transition, l'édition IoT était la dernière variante à ne pas avoir franchi le pas.
Fedora sera construit avec DNF 5 en interne. Ainsi les outils Mock, Koji et Copr passent le cap, en attendant Fedora Linux 41 pour que cela soit le cas pour les utilisateurs de la distribution. L'objectif est ici double. Les développeurs de DNF auront un retour d'expérience grandeur nature sur cette version et permettra d'identifier d'éventuels problèmes. Pour l'infrastructure, DNF 5 est plus léger en mémoire, plus performant et consomme moins d'espace disque ce qui permettrait de gagner du temps dans la construction des RPM et des images et de réduire la pression sur le matériel employé à ces tâches.
Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros. Ces projets sont maintenant distincts upstream et ce premier dépend maintenant du second. L'objectif est de simplifier la possibilité d'exécuter des tests automatiques sur ces macros afin d'améliorer leur fiabilité.
Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. L'objectif de cette phase est de poursuivre le travail entamé dans les versions précédentes en convertissant l'essentiel des paquets RPM vers ce nouveau format. Cependant le travail devrait être achevé pour l'ensemble des paquets pour Fedora Linux 41.
La construction de certains paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction. C'est la macro %{hardened_build
} qui est étendue pour fournir ce service, cela ne concerne que les paquets l'utilisant. Il peut ainsi générer une telle erreur s'il détecte une pile exécutable, un segment chargeable en mémoire avec des permissions en lecture, écriture et exécutable ou un fil d'exécution local ayant un segment exécutable. L'objectif est donc de renforcer le caractère non modifiable des sections mémoires exécutables pour limiter le risque de failles de sécurité. Cela est fait grâce à l'éditeur de lien BFD qui fournit de telles vérifications. Jusqu'à présent ces cas étaient détectés mais ne généraient que des avertissements qui étaient de fait ignorés.
Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C. L'objectif est de supprimer de plus en plus de code utilisant d'anciennes constructions qui sont source de bogues d'une part, mais qui seront aussi progressivement interdites par défaut avec les futures versions de GCC. Par ailleurs, certains de ces éléments pouvaient être bloquants pour l'adoption d'une nouvelle norme C de référence pour certains paquets.
Voici la liste des changements opérés :
intquand le type est omis : 5 paquets concernés ;
returndoit avoir les arguments qui correspondent au type de retour d'une fonction (donc pas d'argument si
void, et non vide si un entier est attendu par exemple) : 13 paquets concernés ;
Certains changements devraient voir le jour dans le futur :
bool,
trueou
falseavec des définitions locales plutôt que d'utiliser l'en-tête de la bibliothèque standard ;
void foo()aurait le même sens qu'en C++, à savoir équivalent à
void foo(void)plutôt qu'à accepter n'importe quel type d'arguments.
Clap de fin pour la construction des mises à jour au format Delta RPM. Ils sont désactivés par défaut dans la configuration de DNF et Fedora ne les générera plus. Cette fonctionnalité permettait pour les mises à jour de ne télécharger que la différence entre le paquet déjà installé et celui à mettre à jour. Cela permettait de réduire la quantité de données à télécharger, la machine de l'utilisateur pouvait reconstruire le paquet à partir de ces informations et ainsi obtenir la nouvelle version. Mais en pratique la fonctionnalité se révèle de moins en moins pertinente. Tout d'abord le processus n'est pas fiable à 100%, parfois la reconstruction échoue et dans ce cas le nouveau paquet est totalement téléchargé à nouveau ce qui conduit à un gaspillage de ressources. De plus peu de paquets étaient concernés, les delta RPM étaient d'ailleurs construits en général que d'une version à une autre ce qui la rend fonctionnelle surtout pour ceux qui mettent à jour très régulièrement leur système. Et pour que cette fonctionnalité soit exploitable, ces fichiers delta rpm font partie des métadonnées que DNF télécharge. Sauf que c'est le cas même si les delta rpm sont désactivés par l'utilisateur, ou pour les systèmes reposant sur rpm-ostree ou utilisant un GUI comme GNOME Logiciels car PackageKit comme rpm-ostree ne se servent pas de ces métadonnées. Au final cela pénalise toute l'infrastructure qui doit générer et stocker ces données, et beaucoup d'utilisateurs qui subissent les inconvénients sans les avantages le tout pour un gain jugé marginal pour ceux qui s'en servent : moins de 8% de réduction de la taille des téléchargements en moyenne.
Les JDKs ne sont générés qu'une fois, et rempaquetés ainsi à toutes les variantes du système. Pour cela les paquets du JDK sont générés à partir de la version la plus ancienne de Fedora Linux encore maintenue, et le résultat est directement réutilisé pour former les paquets des autres versions du système. Cela réduit considérablement le temps de validation de chaque JDK car il y a cinq fois moins de versions différentes à gérer. Cela permettra aux mainteneurs de maintenir la diversité actuelle des JDK à savoir les versions 1.8.0, 11, 17 et la dernière (actuellement la version 20). Si ce résultat ne permet pas de libérer assez de temps aux mainteneurs, la réduction du nombre de JDK à l'avenir pourrait être considérée.
Les images immuables pour les systèmes personnels comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs. Les noms de variantes Silverblue, Kinoite, Sericea et Onyx vont être préservés, l'objectif est de donner une dénomination commune qui utilise le terme Atomic déjà employé par l'édition Cloud par exemple. Le terme immuable est en effet considéré comme peu clair car si le système principal est majoritairement en lecture seule, il ne l'est pas totalement notamment pour la configuration ou les parties dynamiques du système. Alors que le système repose sur le concept d'atomicité en ayant une approche par état du système, d'où la nécessité de redémarrer pour changer cet état notamment lors d'une mise à jour par ailleurs.
L'objectif est donc purement au niveau de la communication autour de ces systèmes. Cependant les nouvelles variantes devraient utiliser ce terme dans ce nom comme par exemple Fedora XCFE Atomic si jamais cette variante prend vie un jour.
Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.
Nous lançons donc un appel à nous rejoindre afin de nous aider.
L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.
Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuels chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.
Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.
Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour. Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.
La synchronisation du travail se passe sur le forum.
Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.
Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 40. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.
Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.
Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.
De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 40.
Étape 1 : le constat Depuis que j’ai mis en place AdGuard Home, je constate beaucoup de requêtes DNS venant de Jeedom. J’avais déjà constaté cela la dernière fois, mais la solution précédente ne peut plus marcher. En effet, maintenant AdGuard Home gère tous mes DNS à la place d’OpenWRT. De plus, je constate une […]
Cet article Optimiser mon cache DNS avec dnsmasq sous Debian est apparu en premier sur Guillaume Kulakowski's blog.
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.
We provide you with both an infographic and a text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details look at the infographic.
Week: 22 April – 26 April 2024
<figure class="wp-block-image size-full is-style-default"></figure>The purpose of this team is to take care of day-to-day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high-quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL) and Oracle Linux (OL).
CPE has a few members who are working as part of the Community Design Team. This team is working on anything related to design in the Fedora Community.
If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.
The post Infra and RelEng Update – Week 17 2024 appeared first on Fedora Community Blog.
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.
RPMs of PHP version 8.3.7RC1 are available
RPMs of PHP version 8.2.19RC1 are available
The Fedora 39, 40, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.
PHP version 8.1 is now in security mode only, so no more RC will be released.
Installation: follow the wizard instructions.
Announcements:
Parallel installation of version 8.3 as Software Collection:
yum --enablerepo=remi-test install php83
Parallel installation of version 8.2 as Software Collection:
yum --enablerepo=remi-test install php82
Update of system version 8.3 (EL-7) :
yum --enablerepo=remi-php83,remi-php83-test update php\*
or, the modular way (Fedora and EL ≥ 8):
dnf module switch-to php:remi-8.3 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.2 (EL-7) :
yum --enablerepo=remi-php82,remi-php82-test update php\*
or, the modular way (Fedora and EL ≥ 8):
dnf module switch-to php:remi-8.2 dnf --enablerepo=remi-modular-test update php\*
Notice:
Software Collections (php82, php83)
Base packages (php)
Your favorite Linux distribution is X. You test everything there. However, your colleagues use distro Y, and another team distro Z. Nightmares start here: the same commands install a different set of syslog-ng features, configuration defaults and use different object names in the default configuration. I ran into these problems while working with Gábor Samu on his HPC logging blog.
From this blog you can learn about some of the main differences in packaging and configuration of syslog-ng in various Linux distributions and FreeBSD, and how to recognize these when configuring syslog-ng on a different platform.
https://www.syslog-ng.com/community/b/blog/posts/using-syslog-ng-on-multiple-platforms
<figure><figcaption>Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to update or rebase to Fedora Linux 40 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Prior to actually doing the rebase to Fedora Linux 40, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
<figure class="wp-block-image size-full is-style-default"></figure>First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
<figure class="wp-block-image size-full"></figure>Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update is completed. After the restart you will end up in a new and shiny release of Fedora Linux 40. Easy, isn’t it?
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 40 using the terminal is easy. First, check if the 40 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/40/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status $ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status $ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 40 branch.
$ rpm-ostree rebase fedora:fedora/40/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 40.
If anything bad happens (for instance, if you can’t boot to Fedora Linux 40 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 40 and your system will start in that previous version rather than Fedora Linux 40. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 40 and roll back. So why not do it today?
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during rebase of Fedora? For example from Fedora 38 Silverblue to Fedora 40 Silverblue?
Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (38->39 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/40/x86_64/kinoite
Oh, wow. This feels like a big number! I’m proud to announce the 40th release of Fedora Linux, a community-built and community-maintained operating system that belongs to all of us. I’m also happy to note that we’re back on track with an on-time release. Thank you to all Fedora contributors who made that possible, and who have, yet again, made this our best one ever.
This is also a personally exciting number for me, because this marks the 20th release for which I’ve served as Fedora Project Leader. We’ve gone through a lot in this last decade, and I’m incredibly happy to see our community thrive and grow. In addition to many long-familiar names and faces, it’s exciting to see a new generation with new energy and ideas. In some cases, this is literally a new generation, as many of you have grown up with Fedora. But at whatever age, I’m proud we’ve built such a welcoming and friendly community, and that we continue to work at improving our inclusiveness, diversity, and accessibility.
But anyway! Enough of that. Time to see what we’ve got for you in Fedora Linux 40! If you have a system already, Upgrading Fedora to a New Release is easy. If you’re new, or just curious, head to Get Fedora for installation options.
Fedora Workstation Edition features the GNOME desktop environment, now updated to version 46. Check out What’s New in Fedora Workstation 40? for the highlights!
The KDE Spin now includes KDE Plasma 6, and runs with Wayland out of the box. Read more about that and other KDE Spin updates at What’s New in Fedora KDE 40?
We’re also officially reviving the “Fedora Atomic Desktop” brand for all of our variants which use ostree or image-based provisioning. Our technology isn’t really “immutable”, so this provides a better grouping. Read more about this at Introducing Fedora Atomic Desktops — but in short, Fedora Silverblue and Fedora Kinoite will remain, while the other desktop variants will become Fedora Sway Atomic and Fedora Budgie Atomic.
Fedora Linux 40 ships with our first-ever PyTorch package. PyTorch is a popular framework for deep learning, and it can be difficult to reliably install with the right versions of drivers and libraries and so on. The current package only supports running on the CPU, without GPU or NPU acceleration, but this is just the first step. Our aim is to produce a complete stack with PyTorch and other popular tools ready to use on a wide variety of hardware out-of-the-box.
We’re also shipping with ROCm 6 — open-source software that provides acceleration support for AMD graphics cards. We plan to have that enabled for PyTorch in a future release.
As usual, we’ve rebuilt everything in the distribution using updated compilers and libraries (and, of course, those updated tools are ready for developers to use). These updates bring bugfixes, security improvements, and performance gains.
And, of course, hundreds of Fedora packagers and testers have worked to integrate the latest versions of open source software from thousands of upstream projects. Those projects, in turn, are made by an uncountable number of developers and contributors working on marketing, design, documentation, code, quality, translations, communications, events, governance, infrastructure, security, and so much more. Thank you again to everyone who makes Fedora amazing, and to everyone whose work has built this whole universe of free and open source software.
There are several important release-day bugfix and security updates available today as well. If you upgrade from an earlier Fedora Linux release, you’ll get them as part of that. For new installations, please make sure to check for and apply updates as soon as possible.
If you run into a problem, visit our Ask Fedora user support forum. This includes a category for common issues.
Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself.
Also, remember that our annual contributor conference, Flock To Fedora, is coming up! It’ll be in Rochester, New York this August. The call for session proposals is still open, if you have something you’d like to share or work on. If you’re already a Fedora contributor, or are interested in being one, or think you might be, we’d love to see you there!
The response from the Fedora community to the Fedora Slimbook 16” and 14” has been great! More and more people are noticing the quality of these laptops. We’ve even had a demo unit at events like FOSDEM and SCaLE for community members to play with.
To build on that excitement, Slimbook and the Fedora Project are announcing Slimbook Fedora 2!
The Slimbook Fedora 2 comes in the 14” and 16” models and brings with it fantastic new options.
Of course we can’t forget that the Slimbook Fedora 2 will also come with the Fedora logo engraved on the lid, as well as on the super key.
This hardware update comes with a software upgrade courtesy of Fedora’s latest release, Fedora Workstation 40. Featuring GNOME 46 and numerous other enhancements, Slimbook Fedora 2 continues to be a great travel companion. Fedora Linux 40 also comes with the latest Nouveau drivers to give you a much better out of the box experience with the Nvidia graphics card in the 16” model.
Slimbook is dedicated to supporting open source initiatives. As part of that, 3% of the proceeds from each Slimbook Fedora unit sold will continue to be donated to the GNOME Foundation.
Besides that there is also the Fedora contributor discount which gives you an additional €100 off! If you’re a contributor to the Fedora Project you can find more info on how to get this discount from this Community Blog post.
Additionally, Slimbook offers a €150 discount for everyone on last year’s model. You can purchase the previous model with a discount through this link: https://fedora.slimbook.com.
<figure class="wp-block-gallery has-nested-images columns-default is-cropped wp-block-gallery-1 is-layout-flex wp-block-gallery-is-layout-flex"> <figure class="wp-block-image size-large"></figure> <figure class="wp-block-image size-large"></figure> <figure class="wp-block-image size-large"></figure> <figure class="wp-block-image size-large"></figure> </figure>More details below:
Check out both new Slimbook Fedora 2 models at https://fedora.slimbook.com/!
Additional Resources
Fedora Linux is a community developed and maintained operating system. Fedora KDE is one of our adaptations of Fedora Linux for your laptop or desktop. With this milestone release of Fedora KDE 40, we hope that you’ll be interested in trying an OS that belongs to you from start to finish, from install to first shut down, from UI customizations to major changes under the hood!
The all-encompassing change in Fedora KDE 40 is the introduction of KDE Plasma 6. It’s the first major release of the Plasma desktop environment in nine years! Additionally, Fedora KDE is one of the first major distros to ship Plasma 6, and we’re the first Fedora Linux desktop variant to ship Wayland-only (not to worry, we retain full support for X11 applications!), enabling the project to push forward improvements to Wayland for the benefit of the entire Linux community. This builds upon the work done in previous Fedora Linux releases to have Fedora KDE run in Wayland from login to shutdown by default.
<figure class="wp-block-image size-large"></figure>You can find more changes and improvements in KDE Plasma 6 from their megarelease page!
If you have an interest in what all of the immutable / atomic / cloud-native / composable / image-based fuss is about, Fedora Atomic Desktops is a great entry point into that world. Case in point, check out Fedora Kinoite 40, an atomic implementation of Fedora KDE that also comes with Plasma 6!
All of the fun events Fedora has coming up!
Thanks for learning about Fedora KDE 40. We hope that it will continue to be the reliable and exciting desktop OS you know and love. Share your appreciation or feedback on social media with #FedoraKDE!
Fedora Workstation, the flagship open source Linux desktop OS from the Fedora Project, has reached a new milestone with the release of Fedora Workstation 40. This release has been made possible due to the contributions of our global community, including your contributions! Fedora Workstation 40 comes packed with new features and performance enhancements that promise a smoother and more responsive computing experience. Read on to learn about the latest features and improvements in the sections below. You can download Fedora Workstation 40 from the Fedora Workstation webpage, or upgrade your existing install within the Software app or with dnf system-upgrade in your favorite terminal emulator.
Fedora Workstation 40 features GNOME 46, the latest version of the GNOME desktop environment. Key updates include a notable upgrade of the Files app, introducing new features and enhancements. Additionally, many aspects of accessibility have received improvements, ensuring a more inclusive user experience. The Settings app and other core apps have been refined for better usability. More details can be found in the GNOME 46 release notes.
Many other improvements have been made throughout GNOME 46, such as:
GNOME’s core applications have had significant improvements in the new version. Some of these include:
GNOME 46 comes with exciting updates to the Settings app, making it more user-friendly than ever. The latest version has more keyboard mnemonics which make navigation easier. It also has a sleek modern interface. The appearance settings load faster than before and with sharper previews. This new release provides more precise control of Wacom stylus pressure.
In addition to the upgrades mentioned above, the Settings app has received major improvements that are worth mentioning:
Other changes to the Files app include a new search field within the Files preferences. It helps find specific settings. There’s now also an option to show date and time in a consistent format, and improved network discovery. These refinements make managing files more efficient.
GNOME 46 provides substantial under-the-hood improvements for a more efficient and polished experience. Key improvements include:
Fedora Linux 40 features many under-the-hood changes. Here are some notable ones:
Cool happenings throughout the Fedora Project!
Stay tuned and get ready to engage with the Fedora community at some upcoming events! In June, join us in Brno, Czechia, for the DevConf CZ conference — a gathering filled with insightful discussions, workshops, and the chance to meet fellow enthusiasts.
Then, mark your calendars for August, when our flagship contributor conference, Flock, takes place. For more details on Flock 2024, check out this post.
And what a week it was! Fedora Linux 40 got the ‘GO’ at the Go/No-Go meeting on Thursday so that means a brand new release of Fedora Linux is arriving to you tomorrow, Tuesday 23rd April!
Read on to hear about other exciting Fedora news
The CfP for Flock to Fedora has been extended until Monday April 29th, so dont delay if you have been thinking about submitting something – here is your chance!
Devconf.us is returning this year in Boston, MA from August 14th – 16th. Their cfp is closing today, so get it in quick if you have had something in draft.
Now that F40 is releasing, attention will be on the development of F41 which has been happening for a while now. Here are some deadlines for all you change proposal enthusiasts, and for other key dates like the beginning of the Beta freeze and mass rebuild, please view the release schedule.
If you are unsure of how to propose a change, there is some excellent documentation and video tutorial to help, and you can always reach out directly to me too.
Changes currently in discussion are:
A full list of the already accepted changes for Fedora Linux 41 can be found on the change set page too.
The F40 elections will begin soon! There are some changes to this cycle, which you can read about them in more detail in the Elections blog post coming later this week and do consider nominating yourself or someone you think would be a great person on Council, FESCo, Mindshare or EPEL when the nominations page is live. Please do make sure the person you are nominating is on board with their nomination too
Help is always greatly appreciated.We also have some packages needing some new maintainers and others needing reviews. See below links to adopt and review packages!
The post Fedora Ops Architect Weekly appeared first on Fedora Community Blog.
The Flock to Fedora 2024 call for proposals (CFP) is now extended to Monday, April 29th 2024 at 11:59 PM US Eastern. Now is the last chance to get your great idea or topic into the Flock 2024 CFP before it closes. This will be the only extension and the new deadline is final.
See the previous announcement for more details about the Flock 2024 CFP. You can also submit directly at cfp.fedoraproject.org. For general questions about Flock and the CFP, join the Fedora Chat room on Matrix, #flock:fedoraproject.org.
The post Flock 2024 CFP extended to April 29th appeared first on Fedora Community Blog.
Please join us at the next regular Open NeuroFedora team meeting on Monday 22 April at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance). Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.
You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:
$ date -d 'Monday, April 22, 2024 13:00 UTC'
The meeting will be chaired by @ankursinha. The agenda for the meeting is:
We hope to see you there!
packit dist-git init
now allows specifying --version-update-mask
option and also any arbitrary top-level configuration options. (packit#2288)/packit test
comment command: in case there is a missing build for some target, the build will not be triggered anymore, it will just be reported to the user. We needed to make this change as with the increased complexity of the configuration (multiple test jobs), the previous implementation was prone to race conditions leading to wasting of resources of Copr and Testing Farm. (packit-service#2399)