/rss20.xml">

Fedora People

Open Source talk at KTH computer science students organization

Posted by Kushal Das on 2024-12-14 11:17:39 UTC

screenshot of the talk page

Last Tuesday, during lunch hours I had a talk at KTH computer science students' organization. The topic was Open Source and career. My main goal was tell the attendees that contribution size does not matter, but continuing contributing to various projects can change someone's life and career in a positive way. I talked about the history of the Free Software movement and Open Source. I also talked a bit about Aaron Swartz and asked the participants to watch the documentary The Internet's Own Boy. Some were surprised to hear about Sunet's Open Source work.

photo of KTH logo on the building

There were around 70 people and few people later message how they think about contribution after my talk. The best part was one student who messaged next day and said that he contributed one small patch to a project.

I also told them about PyLadies Stockholm and other local efforts from various communities. There was also a surprising visit of the #curl channel on IRC, thanks to bagder and icing :)

When Your Webcam Doesn’t Work: Solving Firefox and PipeWire Issues

Posted by Jan Grulich on 2024-12-13 12:15:42 UTC

If you are a regular reader of my blog posts, as I am sure you are, you will know that we made a switch with Fedora 41 and now use PipeWire as the default backend for camera handling in Firefox. It won’t come as a surprise that such a huge change is not without its problems. After talking to many of you and debugging the same issues over and over again, I would like to go through most of the common issues and show you how to fix them, and also shed some light on the whole stack.

For Chrome/Chromium users out there, most of the issues mentioned here also apply to you, as most of the PipeWire camera code is shared in WebRTC, but I must mention that the PipeWire camera is completely broken in M131 and fixed in M132.

Issue #1 – Permission issue – “Camera is blocked” or “The request is not allowed” etc.

This is the most common problem and is usually caused by the user not giving access to the camera to an application that is requesting it. When Firefox wants to use a camera, it makes a request to the camera portal (xdg-desktop-portal). This results in a system dialogue asking for camera access for Firefox. If access is granted, it will be granted for all future sessions, but if access is denied or the dialogue is closed, it will remember this decision and all future requests to use the camera will be automatically denied.

You can check this by running:

$ flatpak permissions devices camera
Table   Object App                 Permissions Data
devices camera                     yes         0x00
devices camera org.mozilla.firefox yes         0x00

In the result you will see that “org.mozilla.firefox” has “yes” stored in the permission store. There is also an empty entry with “yes” stored. The empty entry is usually for applications for which we were unable to get an application id. This happens for host applications that are launched in an unusual way, such as the Alt + F2 command or from a terminal. If you have a permission problem, you will most likely see “no” stored there, and this is what is causing the problem for you.

You can clear this and be prompted again for camera access running this command:

flatpak permission-remove devices camera org.mozilla.firefox

You may be wondering why flatpak is involved, since you don’t use flatpak applications. Flatpak is not really necessary, but I use its command line to work with the permission store and it is easier for me to just give you a command and you give me the result, otherwise you could also use Flatseal to check your camera permissions. The permission store comes from portals (xdg-desktop-portal), which we use to get access to your camera. While portals were originally intended to be used mainly by sandboxed applications (Flatpak, Snap), they are now also used for things like screen sharing (Wayland) and now the PipeWire camera, making them an essential part of the Linux desktop stack. Always make sure that xdg-desktop-portal is installed with a specific portal backend for your desktop, e.g. xdg-desktop-portal-gnome for GNOME or xdg-desktop-portal-kde for Plasma.

Issue #2 – No camera found

This can be a problem with many components. Let’s start with the most important one, which is finding out if Wireplumber (the session and policy manager for PipeWire) detects it.

You can run:

$ wpctl status
Video
 ├─ Devices:
 │      50. Integrated Camera                   [v4l2]
 │      62. Integrated Camera: Integrated C     [libcamera]
 │      63. Integrated Camera: Integrated I     [libcamera]
 │      69. Integrated Camera                   [v4l2]
 │      85. Integrated Camera                   [v4l2]
 │      93. Integrated Camera                   [v4l2]
 │  
 ├─ Sinks:
 │  
 ├─ Sources:
 │      76. Integrated Camera (V4L2)           
 │  *   80. Integrated Camera (V4L2)           
 │  
 ├─ Filters:
 │  
 └─ Streams:

Here we are mainly interested in “Sources“, as this is what will appear in Firefox. Typically, most laptop cameras appear here twice, as one is an infrared camera for Windows Hello support, which we already filter out in Firefox. If your camera doesn’t appear there, it won’t work in Firefox or any other application that uses PipeWire.

If your camera is listed there but doesn’t appear in Firefox, I usually recommend that people try OBS Studio, which has great support for PipeWire cameras. This will always tell you if the problem is in Firefox or somewhere else. If it works in OBS Studio, you can open a bug to Firefox with all the necessary information (see below). If not, it is probably a bug in PipeWire.

We are already tracking one issue with the v4l2 plugin in PipeWire. This is most likely a race condition for which we have at least a workaround in the form of switching from v4l2 to libcamera.

In order to use libcamera, you can create following file:

$HOME/.config/wireplumber/wireplumber.conf.d/99-libcamera.conf

With the following content:

wireplumber.profiles = {
 main = {
   monitor.v4l2 = disabled
   monitor.libcamera = optional
  }
}

And restart both Wireplumber and PipeWire:

systemctl --user restart pipewire wireplumber

If this doesn’t solve the problem for you, please follow the instructions below to report a bug to Firefox.

Another known problem, probably a rare one, is if you restart PipeWire while Firefox is still running. This is because we keep a connection to PipeWire and when you restart it, that connection is broken and not initialised again. This problem affects OBS Studio in the same way and I’m already working on a fix. The solution here is to restart Firefox.

Debugging and reporting issues to Firefox

You came here because none of the above worked? You can still report a bug with all the necessary information to help us identify the problem. First, you want to report a bug to Firefox upstream. You can do this here by selecting the “Core” product and the “WebRTC: Audio/Video” component and providing all the logs from below.

Include DBus communication with xdg-desktop-portal.

Open a terminal of your choice and run:

dbus-monitor --session

Keep it running, while you try to access the camera in Firefox. For example, using the WebRTC getUserMedia test page. You should see all the DBus communication in the log from dbus-monitor.

Also a useful information might be to know whether the camera portal see any camera by running:

dbus-send --print-reply --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.DBus.Properties.Get string:"org.freedesktop.portal.Camera" string:"IsCameraPresent"

Including log from Firefox by running it with:

MOZ_LOG="MediaManager:5,CamerasParent:5,CamerasChild:5,VideoEngine:5,webrtc_trace:5"

And a log from:

pw-mon

Which will provide all advertised formats by your camera and supported formats by Firefox.

Last resort

Once you have done your duty and opened a bug with all the above information, which I’m really grateful for, you can now go to “about:config” in Firefox, disable “media.webrtc.camera.allow-pipewire” and restart Firefox. This will switch back from PipeWire to v4l2, but I hope you will accept this as a temporary solution until we can identify and fix your problem.

Debugging and reporting issues to Chromium

All the logs you can provide also apply to Chrome/Chromium, with the exception to logs from the app itself.

In order to get logs from Chrome/Chromium, you need to run it with:

google-chrome --enable-logging --vmodule=*/webrtc/*=1

Once you have collected all the necessary logs, you can open a bug here for the “CameraCapture” component and add me to the bug (use grulja AT gmail.com) or let me know at least so I’m aware.

To switch back from PipeWire to v4l2 you have to go to “chrome://flags” and disable “PipeWire Camera support“, but you already know that since you had to enable it yourself before :).

Infra and RelEng Update – Week 50 2024

Posted by Fedora Community Blog on 2024-12-13 10:00:00 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. 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: 09 – 13 December 2024

Infrastructure & Release Engineering

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

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

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 50 2024 appeared first on Fedora Community Blog.

EPEL 10 is now available

Posted by Fedora Community Blog on 2024-12-12 20:00:00 UTC

On behalf of the EPEL Steering Committee, I’m happy to announce the availability of EPEL 10. EPEL 10 already contains over 10,000 packages, built from over 3,600 source packages. This is a result of the hard work of over 150 Fedora package maintainers.

What is EPEL?

Extra Packages for Enterprise Linux (EPEL) is an initiative within the Fedora Project to provide high quality additional packages for CentOS Stream and Red Hat Enterprise Linux (RHEL). The goal for EPEL packages is to enhance these distributions, without disturbing or replacing packages from the default repositories.

What’s new?

For the EPEL 9 release, we started building packages about six months before the RHEL 9 release by using CentOS Stream 9 as the initial build environment. For EPEL 10, we’re expanding on that approach and doing the same thing for each minor version of RHEL 10. We will have separate DNF repositories for each minor version of RHEL 10, including CentOS Stream 10 as the leading minor version. Packages built for one minor version will carry forward to the next minor version. You can find more details about this structure in our branching documentation.

Requesting packages

While many packages are already available in EPEL 10, it’s possible that your favorite package isn’t one of them yet. We don’t automatically branch packages from the previous major version to the next major version. Individual package maintainers opt-in to building for each new major version. You can request additional packages by following our package request guide.

Getting started

Ready to start using EPEL 10? Check out our getting started guide for instructions to set up the repository on your system.

The post EPEL 10 is now available appeared first on Fedora Community Blog.

IPU6 camera support is broken in kernel 6.11.11 / 6.12.2-6.12.4

Posted by Hans de Goede on 2024-12-12 13:52:47 UTC
Unfortunately an incomplete backport of IPU6 DMA handling changes has landed in kernel 6.11.11.

This not only causes IPU6 cameras to not work, this causes the kernel to (often?) crash on boot on systems where the IPU6 is in use and thus enabled by the BIOS.

Kernels 6.12.2 - 6.12.4 are also affected by this. A fix for this is pending for the upcoming 6.12.5 release.

6.11.11 is the last stable release in the 6.11.y series, so there will be no new stable 6.11.y release with a fix.

As a workaround users affected by this can stay with 6.11.10 or 6.12.1 until 6.12.5 is available in your distributions updates(-testing) repository.



comment count unavailable comments

The real problem with end-of-life software

Posted by Ben Cotton on 2024-12-11 13:00:00 UTC

You’re probably aware of the risks of using software that has reached end-of-life (EOL). New vulnerabilities go unfixed. If you need new features or compatibility fixes, you’re out of luck. This presents both a functional and security risk. But no software is truly end-of-life if you can write a big enough check. No, the real problem with end-of-life software is knowing what end-of-life actually means.

When a project defines a lifecycle for it’s software, it’s pretty easy to tell what end-of-life means. As part of the lifecycle, the project documents the level of support a particular version gets and when that support period ends. The project may say “we’ll fix bugs for six months, and then only fix security issues for another six months after that.” There may be several levels of varying lengths.

But what happens if the maintainers just sort of…disappear? If a project hasn’t had an update in two years, is it because it’s complete or because it’s abandoned? How can you tell?

Services like endoflife.date and standards efforts like OpenEOX can help you know when the software you depend on has reached end-of-life, but only if the project makes — and shares! — and explicit EOL determination. When a project is abandoned or the flywheel slows, how can you tell? The ultimate risk is the same as with an explicit date, but you don’t know about it.

So how can we fix this? The short answer is: we can’t. You can’t force your upstreams to provide a lifecycle policy because they are not your supplier. The best we can do is pay attention when that information is available and set a good example in our own projects. Not every maintainer will be willing to make that commitment, which is fine. The more projects that adopt an explicit lifecycle, though, the better of we’ll all be. Chapter 7 of Program Management for Open Source Projects describes creating a lifecycle for your project’s releases.

This post’s featured photo by Matt Artz on Unsplash.

The post The real problem with end-of-life software appeared first on Duck Alignment Academy.

dist-git outage

Posted by Fedora Infrastructure Status on 2024-12-11 10:30:00 UTC

We will switch authentication from OpenID to OIDC (OpenID Connect). There will be a short outage to do this.

Fedora Project Leader Matthew Miller: A change of hats!

Posted by Fedora Magazine on 2024-12-10 17:00:00 UTC

Okay, wow… deep breath….

Hi everyone!

I’ve been the Fedora Project Leader for more than ten years. That’s half of Fedora’s existence as a distribution project. It is my dream job, and I love it, and honestly, I could do it forever.

However, I don’t think I should do it forever. When I started in this role, I thought: I’m going to aim for five years.  But, when I got there, I felt like I’d just found my footing. We had a series of great releases, a super-productive Fedora Council meetup in Minnesota, and Flock to Fedora in Budapest was amazing. With that energy, I saw so much more to work on. I definitely wasn’t done.

Now, after another five years, it’s time. The project is in great shape. We have high community engagement, stronger support than we’ve seen in years from our major sponsor, and increasing popularity and visibility in the whole Linux world. We build the distro of choice for new CPU architectures like RISC-V, and vendors ship our OS on laptops. Atomic  image mode is awesome. We’re on a good path for big infrastructure improvements.1 I want all this to keep expanding — and more! To get there, I think we need someone with new energy and fresh ideas standing in my place.

Stay tuned for a job posting from Red Hat, and details about all that. I’m hoping we can hire someone awesome early in 2025, and make the official handover on the release of auspiciously-numbered Fedora Linux 42.

I’m not going to leave Fedora, though. As I said above, although it might not always feel like it from the outside, Red Hat support for Fedora is stronger than ever, and I plan on helping that grow even more. I’m stepping into a full-time management role in the Community Linux Engineering organization, so Fedora will still be part of my day job, just in a different way2.

Likewise, I’ll be nearby as a resource for the incoming FPL. This is a big, difficult job, and I know from experience (thanks, Robyn!) that it’s crucial to have someone close who understands what it’s like to provide support. I want the next person to feel confident and up-to-speed in quite a lot less than five years.

Thank you, everyone, for making Fedora the best Linux distro ever. Thank you for listening to my good ideas and being patient with many more bad ones. I would not be here without your support and friendship all these years, through difficult times and amazing times3. I love you all!

– Matthew


  1. New git forge, better CI, a more modern and flexible build system, more workflow automation… and I’ll convince you all to switch from mailing lists to Discourse, eventually! ↩
  2. Actually, that’s a lie. The first thing I’m going to do is sleep for a month. But, after that. ↩
  3. Often, both at once. ↩

Please direct replies and comments to the announcement on Fedora Discussion. Thank you!

F41 Elections Voting is now Open!

Posted by Fedora Community Blog on 2024-12-09 20:57:39 UTC

Voting in the Fedora Linux 41 elections is now open. Go to the Elections app to cast your vote. This cycle we have just one election to vote in – FESCo. Voting closes at 23:59 UTC on Friday, 20thDecember and don’t forget to claim your “I Voted” badge when you cast your ballot. Links to candidate interviews are below.

Fedora Engineering Steering Committee (FESCo)

There are five seats open for the Fedora Engineering Steering Committee (FESCo).

Mindshare Committee

As one of the nominees for the Mindshare Committee is already an active elected member, Sumantro Mukherjee, the current eligible nominee number matches the open seats, and so the eligible nominated candidate will be automatically elected in. Early congratulations, Luis Bazan!

The post F41 Elections Voting is now Open! appeared first on Fedora Community Blog.

FESCo election: Interview with Zbigniew Jędrzejewski-Szmek

Posted by Fedora Community Blog on 2024-12-09 20:52:50 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora Account: Zbigniew Jędrzejewski-Szmek
  • Nick: zbyszek
  • Matrix Channels typically found in: fedora-devel, fedora-python, systemd, mkosi
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I see the role of FESCo as a place where all voices are heard so that a consensus decision can be reached. It is individual community members, SIGs, and other groups who should propose and implement changes. FESCo is the place where questions about motivation, backwards compatibility, user experience, schedules and contingency plans are asked and answered. I think it’s totally fine when the majority of decisions by FESCo is unanimous after that.

Overall, I think Fedora is doing OK. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. The release of F39 was delayed, but this can be attributed to internal Red Hat problems. I hope we’re past this and will be back on track for F40.

To maintain the position of Fedora as the most innovative distro, we need to keep adapting and implementing big new initiatives. I would love to see Fedora more widely used, with more packages delivered more reliably. I very much support the FPL’s goal to double the number of contributors. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.

We have a number of initiatives that improve specific areas, but we’re not doing enough to build tools and procedures that provide a uniform and consistent experience. For example, we have rpmautospec, but it’s not universally used. We have automatic bodhi updates for rawhide, but the same functionality is not available for stable releases. We have gating, but it’s still very hard to use, with lots of false positives. Packit is being used by some packages, but it’s something on the side, only awkwardly integrated with the normal Fedora packaging infrastructure. We need to build a more coherent packaging experience so that we can do bold, innovative things in Fedora.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I’m active in systemd upstream, and I’ve been doing systemd package maintenance in Fedora since 2013; if you’ve submitted a systemd bug in Bugzilla or in the upstream bugtracker, chances are I’ve looked at it. I maintain a few dozen packages, and I try to do new package reviews regularly (469 so far). I’ve been in FESCo since F28. I’be been involved in various initiatives, like the transition of various upstream to Python 3, mass rename of Python 2 packages during the transition to Python 3, improvements to packaging tools (rust2rpm, rpmautospec), transition of the packaging documentation from the wiki, ELF package notes, reproducible builds, updating of Packaging Guidelines for new techniques. I try to help with all aspects of packaging, but I’m especially interested in mass cleanups and automatization of various packaging processes.

How do you handle disagreements when working as part of a team?

Team members must trust each other and be transparent about their reasoning and motivations. If that is true, technical differences can be explained away or proven with actual code. For all this to work, the group must share a common goal.

What else should community members know about you or your positions?

Continue my wishlist of 2024 into 2025, as I have done in previous election years:

  • Clean up bodhi update gating so that false failures are infrequent and packagers start relying on the status and always consider the results.
  • Figure out how rpmautospec should be used during initial packaging and during review. The documented method before and after review must be consistent.
  • Convert 90+% of packages to SPDX license tags.
  • Set up a continuous rebuilds of rawhide/amd64 to gather statistics on build reproducibility of Fedora packages. Once the common issues have been resolved, plan towards making build reproducibility an official feature.
  • SystemdSecurityHardening
  • continue the work on Unified Kernel Images and non-dracut initrds. This year we should get a pre-built initrd as an option for normal users.

The post FESCo election: Interview with Zbigniew Jędrzejewski-Szmek appeared first on Fedora Community Blog.

FESCo election: Interview with Tomas Hckra

Posted by Fedora Community Blog on 2024-12-09 20:51:18 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Tomas Hckra

  • Fedora Account: Tomas Hckra
  • Nick: jednorozec/humaton
  • Matrix Channels typically found in: fedora-releng, #fedora-devel, #fedora-devel, #fedora-noc
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

As a product owner of Community linux engineer team, I bring to the table insight on the planning and capacity that the team that is running fedora infrastructure, release engineering and Quality has, and this perspective can bring some new opinions into the steering process. My focus is mostly on user/contributor self-service where possible so we can remove obstacles for new people coming into the Fedora project.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Over the last decade, I went through package maintenance and app development. Currently, I am part of the release engineering team, helping out with releases and related infrastructure work. Right now I am working on dropping the Product Definition Center from our workflows so we can reduce the complexity in our package-related processes and tooling.

How do you handle disagreements when working as part of a team?

Most of the team disagreements I was part of were caused by communication issues and misunderstanding of one or the other side. So I strongly believe that most problems are resolvable by listening, considering the other side, and communicating about the disagreement clearly. The next step is building consensus keeping in mind all the viewpoints that caused the conflict in the first place.

What else should community members know about you or your positions?

I am a full-on open-source nerd, everything in my house is running open-source SW. I am not shy of public speaking you can find some of my talks on YouTube like this one about opensource home automation: https://www.youtube.com/watch?v=HUhHaHnzhYA

Two main ideas that define my approach to technology:
“I want all things open and all sources shown”
“Where is a serial console there is a way”

The post FESCo election: Interview with Tomas Hckra appeared first on Fedora Community Blog.

FESCo Election: Interview with Josh Stone

Posted by Fedora Community Blog on 2024-12-09 20:50:28 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Josh Stone

  • Fedora Account: Josh Stone
  • Nick: jistone
  • Matrix Channels typically found in: #rust:fedoraproject.org
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I’m proud of Fedora, both as a user and contributor, and continuing to serve on FESCo would be another way for me to contribute to its success. I don’t have a list of things that I would change in Fedora, but even steering along the current course requires time and attention, and there will always be new changes on the horizon. I think that I have relevant experience to continue to help as an elected member of FESCo.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I maintain the Rust toolchain in Fedora, keeping up with its releases every 6 weeks for all Fedora branches, and sometimes point release in-between. We decided long ago that rolling rebases made the most sense for Fedora, since Rust developers are often eager to use new features. This keeps Fedora relevant for Rust developers, and helps Rust SIG packagers to not worry about the toolchain version when updating crates. I also work closely with the LLVM maintainers, both for coordinating Rust needs and in more general issues.

How do you handle disagreements when working as part of a team?

Disagreements are natural, and the goal should be to reach consensus, which may require difficult conversations about pros and cons and compromise positions. But even then, it’s not always possible to reach agreement, and hopefully in that case there is a governance structure to fall back on — whether that’s a decision maker in a team lead or manager, or a democratic process like voting in FESCo decisions. Ultimately, it’s important to operate in good faith and assume the same in others, and agree to commit and move on when a decision has been made.

What else should community members know about you or your positions?

I’m a member of Red Hat’s Platform Tools team, where I also maintain the Rust toolchain for RHEL. In a previous role, I worked on SystemTap for Fedora and RHEL, giving me broad experience across the entire system. In the upstream Rust community, I’m a member of the library, release, and security-response teams, and I previously served as a Project Directoron the board of the Rust Foundation. So while my current contributions to Fedora are narrowly focused, I think I have a lot to offer in the larger view as a FESCo member.

The post FESCo Election: Interview with Josh Stone appeared first on Fedora Community Blog.

FESCo election: Interview with David Cantrell

Posted by Fedora Community Blog on 2024-12-09 20:49:13 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with David Cantrell

  • Fedora Account: dcantrell
  • Nick: dcantrell
  • Matrix Channels typically found in: fedora-ambassadors, #fedora-ci, #fedora-devel, #fedora-qa, #rpm, and #rpm-ecosystem & you can also ping me directly
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

Fedora is important to me as both a project and a community. I want to continue to help steer Fedora’s engineering direction and ensuring that the project succeeds and grows. Specifically I want to see it continue to embrace more container-based delivery alongside the traditional RPM model. Making Fedora even easier to work with in a container: to maintain, to update, and to deploy. We also have a lot of hardware opportunities and seeing the Asahi Project move to using Fedora as their base was great. On FESCo we discuss all of these sorts of things and more and I want to continue to hear from the users and developers and help guide the project.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Aside from FESCo, I also serve as the engineering representative on the Fedora Council. I am a Fedora Ambassador and a sponsor for new contributors. I maintain a range of packages and am the upstream developer for a number of projects. My recent large project has been the rpminspect program which is used in a handful of CI environments to validate builds and check policy compliance.

I run both the latest stable release of Fedora and rawhide and report bugs when I encounter them and submit patches when possible.

I try to answer questions for as many people as I can and when I can’t, I try to help find someone who can.

How do you handle disagreements when working as part of a team?

In my experience, disagreements come up because everyone is very passionate about the task or topic at hand. It’s important to remember that most of these should end in compromise. I do my best to make my points clear and understood while at the same time listening to everyone else. Sometimes the conversation itself is enough to clear up disagreements. Maybe I didn’t have the full story or maybe someone else didn’t. As long as we are willing to have these conversations and reach a compromise, things go well.

What else should community members know about you or your positions?

My day job is working at Red Hat, where I have been working on RHEL and Fedora full time for 19 years. Prior to that I worked at a number of companies doing Linux development or admin work and even before that I worked on the Slackware Linux distribution.

Outside of work I enjoy restoring old and obsolete computers, making contacts (or actively pretending to make contacts) via amateur radio, and boating in and around Boston Harbor and New England.

I live in Medford, Massachusetts.

The post FESCo election: Interview with David Cantrell appeared first on Fedora Community Blog.

FESCo election: Interview with Fabio Alessandro Locati (Fale)

Posted by Fedora Community Blog on 2024-12-09 20:48:21 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Fabio Alessandro Locati (Fale)

  • Fedora Account: Fale
  • Nick: fale
  • Matrix Channels typically found in: #atomic-desktops:fedoraproject.org, #sway:fedoraproject.org, #golang:fedoraproject.org, #devel:fedoraproject.org, #coreos:fedoraproject.org, #iot:fedoraproject.org, #mobility:fedoraproject.org, #websites:fedoraproject.org, #fedora-arm:matrix.org
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have been around the Fedora community for many years now: my FAS account is dated January 2010 (close to 15 years!), and I’ve contributed with many different hats to the Fedora project. In the beginning, I started as an ambassador, and over time, I’ve also become a packager and a packaging mentor, and I have joined multiple SIGs such as the Golang, Sway, and Atomic Desktop. For many years, I’ve been interested in immutable Linux desktop, Mobile Linux, and “new” languages (such as Go) packaging challenges, which are also becoming more relevant in the Fedora community now. Having contributed to the Fedora Project for a long time in many different areas, and given my experience and interest in other projects, I can bring those perspectives to FESCo.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Currently, most of my contributions fall in the packaging area: I keep updating the packages I administer and try to find different solutions for packaging new languages and maintaining the Sway artifacts.
My current contributions are important to keeping Fedora first, not only in terms of package versions but also in terms of best practices and ways to reach our users.

How do you handle disagreements when working as part of a team?

I think disagreements are normal in communities. I have a few beliefs entering and during any disagreement that guide me. First, I always separate the person from their argument: this allows me to discuss the topic without being influenced by the person making the points. The second believe I always have in mind during disagreements is that all people involved probably have a lot of things they agree on and a few they don’t agree on (otherwise, they would not be part of the conversation in the first place): this allows me to always see the two sides of the disagreement as having way more in common than in disagreement. The third belief I always hold during a discussion is that the people arguing on the opposite side of the disagreement are trying to make sure that what they believe as right becomes a reality: this allows me always to try to see if there are aspects in their point of view that I had not considered or not appropriately weighted.
Thanks to my beliefs, I always manage to keep disagreements civil and productive, which often leads to a consensus. It is not always possible to agree on everything, but it is always possible to disagree in civil and productive ways.

What else should community members know about you or your positions?

Let’s start with the fact that I’m a Red Hat employee, though what I do in my day job has nothing to do with Fedora (I’m a specialist for Ansible, so I have nothing to do with RHEL as well), so I have no alter motives around my contributions. I use Fedora on many devices (starting from my laptop) and have done so for many years. I contribute to the Fedora Project because I found in it and its community what I deem to be the best way of creating the best operating system :).
I’ve been using Sway exclusively on my Fedora desktop since I brought it in Fedora in 2016. On the other systems, I use either Fedora Server, Fedora CoreOS, or Fedora IoT, even though lately, I prefer the latter for all new non-desktop systems.
I see the Fedora Community as one community within a sea of communities (upstream, downstream, similarly located ones, etc.). I think the only way for all those communities to be successful is to collaborate, creating a higher-level community where all open-source communities collaborate for the greater good, which – in my opinion – would be a more open-source world.

The post FESCo election: Interview with Fabio Alessandro Locati (Fale) appeared first on Fedora Community Blog.

FESCo election: Interview with Kevin Fenzi

Posted by Fedora Community Blog on 2024-12-09 20:45:31 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December 2024.

Interview with Kevin Fenzi

  • Fedora Account: Kevin
  • Nick: nirik
  • Matrix Channels typically found in: #fedora-admin/admin, #fedora-noc/noc, #fedora-releng/releng, #fedora-devel/devel
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I wish to continue to serve the fedora community on FESCo to provide history and help make today’s decisions based on yesterdays learning.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I currently am lucky to be employed by Red Hat working full time on Fedora Infrastructure. But outside of that ‘day job’ I try and do as many things as I can to help the fedora community: Maintaining packages, providing feedback on plans or ideas, doing release engineering tasks (often in non ‘work’ times).

How do you handle disagreements when working as part of a team?

I try and reach consensus until it becomes clear thats not possible. However, it almost always is possible, you just need to look at things from other perspectives and consider what solution would work for everyone. This is not foolproof, but helps to handle disagreements when they happen.

What else should community members know about you or your positions?

I’m happy to talk to anyone from the community anytime about fedora items. Feel free to contact me on matrix or email. I’m human and make mistakes, but I like to think I learn from them and do better over time. 🙂

The post FESCo election: Interview with Kevin Fenzi appeared first on Fedora Community Blog.

Infra and RelEng Update – Week 49 2024

Posted by Fedora Community Blog on 2024-12-06 10:00:00 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. 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: 2 – 6 December 2024

Infrastructure & Release Engineering

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

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

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 49 2024 appeared first on Fedora Community Blog.

Contribute at the IPA Migrate Test Day

Posted by Fedora Magazine on 2024-12-06 08:00:00 UTC

The IDM/IPA team is working on testing the new IPA (Identity Policy Audit) migrate feature and functionality. As a result, the Identity Management and QA teams have organized a test day on Monday, December 09, 2024. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.

How does a test week work?

A testday is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

  • Download test materials, which include some large files
  • Read and follow directions step by step

The wiki page has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test week web application. If you’re available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on the test day.

PHP version 8.2.27RC1, 8.3.15RC1 and 8.4.2RC1

Posted by Remi Collet on 2024-12-06 06:52:00 UTC

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.4.2RC1 are available

  • as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

RPMs of PHP version 8.3.15RC1 are available

  • as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

RPMs of PHP version 8.2.27RC1 are available

  • as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

emblem-notice-24.png The packages are available for x86_64 and aarch64.

emblem-notice-24.pngPHP version 8.1 is now in security mode only, so no more RC will be released.

emblem-notice-24.pngInstallation: follow the wizard instructions.

emblem-notice-24.png Announcements:

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

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.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.3:

dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.2:

dnf module switch-to php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*

emblem-notice-24.png Notice:

  • version 8.4.2RC1 is in Fedora rawhide for QA
  • EL-10 packages are built using RHEL-10.0-beta
  • EL-9 packages are built using RHEL-9.5
  • EL-8 packages are built using RHEL-8.10
  • oci8 extension uses the RPM of the Oracle Instant Client version 23.6 on x86_64 or 19.24 on aarch64
  • intl extension uses libicu 74.2
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
  • versions 8.2.27, 8.3.15 and 8.4.2 are planed for December 19th, in 2 weeks.

Software Collections (php82, php83, php84)

Base packages (php)

The syslog-ng newsletter looks odd

Posted by Peter Czanik on 2024-12-05 14:14:54 UTC

Recently I was asked why the syslog-ng newsletter looks odd. At first I did not even understand what is the problem. Then I realized that I kept using the same format for the past 14 years, that was optimized for UNIX terminals :-)

So, what is the problem? 14 years ago I was kindly asked by syslog-ng users to use plain text e-mails instead of HTML formatting. Of course it also means that there is no easy way to emphasize titles in the newsletter. For that I started to use a long list of hyphens under the titles, equal length to the title. It all looks perfect in a terminal window, which has fixed width fonts. It definitely looks odd in a GUI e-mail client, which does not use fixed width fonts. Something like this:

This is a really nice title

---------------------------

The lenght of the line and the title are different. Luckily the mailing list archive also uses a fixed width font when showing e-mails. So, if you take a look at the last syslog-ng newsletter, you will see that it looks completely OK: https://lists.balabit.hu/pipermail/syslog-ng/2024-December/026735.html

So, what is next? My suspicion is that over the past decade even the most diehard terminal users started to use graphical e-mail clients (most likely a web browser). Starting next year I’ll switch to HTML formatting, hoping that nobody will complain :-)

syslog-ng logo

The syslog-ng Insider 2024-12: FreeBSD audit; 4.8.1; conferences

Posted by Peter Czanik on 2024-12-05 10:07:40 UTC

The December syslog-ng newsletter is now on-line:

  • FreeBSD audit source for syslog-ng

  • Version 4.8.1 of syslog-ng is now available

  • Where should I present syslog-ng and sudo?

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-12-freebsd-audit-4-8-1-conferences

syslog-ng logo

Potential failures in the upcoming mass rebuild

Posted by Yaakov Selkowitz on 2024-12-05 00:00:00 UTC

There are less than six weeks until the Fedora 42 mass rebuild. While mass rebuilds inevitably result in some breakage, the following issues appear likely to be common causes of FTBFS:

GCC 15

While not yet announced as a change for Fedora 42, each winter mass rebuild is immediately preceded by a new major (prerelease) version of GCC. (I might still be recovering from GCC 14 which coincided with the branching of RHEL 10.) Each major GCC version ends up introducing some strictness which results in compile errors in existing (particularly older) code. Hopefully we’ll be hearing more from the Tools team about what to expect this time, but in the interim there is a WIP list of major changes.

Automake 1.17

Newly introduced in rawhide just yesterday, this is the first major release in more than six years. The upstream release announcement does not indicate any major incompatibilities, but I have already seen one failure in a package which tried to make now-outdated assumption automake version numbers, and there are likely to be more such changes needed.

Setuptools 74

So far, the major incompatible change here is that the long-deprecated setup.py test is no longer supported, which will break dozens of packages. The Python SIG has already filed bugs for at least some of these. If you haven’t already, now is the time to fix your Python packages by calling the tests directly.

CMake 3.31

Unfortunately, the latest cmake has caused some issues in Qt/KDE land by breaking builds involving QML. Also, there was a regression with the %ctest macro and the double-hyphen separator before short arguments (e.g. %ctest -- -E foo) but that should now be fixed.

glibc 2.41

This may not affect that many packages, but the introduction of struct sched_attr and userspace functions for the sched_getattr and sched_setattr syscalls (upstream commit) has caused conflicts with code which had been providing their own such wrappers. The “proper” way to handle this is to guard these based on configuration tests, but for those that do not do so, !__GLIBC_PREREQ(2,41) will only help once 2.41 is released. In the meantime, workarounds may be necessary (e.g. here and here).

There will likely be more FTBFS themes to emerge in the coming weeks, but it’s not too early to fix your packages for any of the above, and to check for any other issues rebuilding your package in rawhide, particularly if you haven’t rebuilt in a while.

Fedora Moves Towards Forgejo

Posted by Fedora Magazine on 2024-12-04 14:11:35 UTC

The decision to move to Forgejo as the new git forge has reached a new stage. Fedora Linux’s leadership has decided to choose Forgejo as their preferred git forge replacement. There are numerous factors involved in this decision and this article will discuss them, present some background on the process, and invite one more chance for feedback before the formal Fedora Council vote.

Gist of the situation

We’ve known for a long time that the Fedora Project needs a new git forge solution. The software we currently use, Pagure, has served us well. Sadly, it never took off in the wider world. So we had to maintain the Pagure git forge ourselves and use it to build the Fedora Linux releases at the same time. A few years ago, we considered GitLab, and had a lot of discussion… which ultimately didn’t go anywhere. Out of that we got a clear message. It’s important that this crucial part of our infrastructure be free and open source software.

At the Fedora Council’s annual face-to-face meeting in February we discussed a large list of options. By the end of the day, we crossed off all but two: GitLab Community Edition and Forgejo. We also determined that no hosting providers can meet our unique needs; we’ll have to self-host. We then asked the Advanced Reconnaissance Crew (ARC, a subteam of Fedora Infrastructure) to investigate these in more detail. They were particularly asked to look at 1) any show-stopper missing features and 2) maintenance effort and cost.

ARC has presented their initial results (about which Akashdeep goes into detail below). The quick summary: either option could work, and both have some gaps we’ll need to fill. Several things tilt the scales one direction. GitLab CE is “open core”, with some features only in the non-open-source “premium” version (including some we really want). This is both an immediate practical concern and a long-term one. Open core software tends, over time, to get less open (no matter how good the initial intentions). In addition, the Infrastructure team is more comfortable with the Forgejo codebase and the language it is written in.

So, what’s next? The Council, currently, has a clear preference for Forgejo. This is a big decision and we don’t want it to feel rushed. Therefore, we’re opening this up one last time to everyone’s comments. We have created a discussion thread referencing this article to submit your feedback to. You can find it using the #git-forge-future tag. After two weeks, we’ll take our formal vote — and then get on with the work!

– Matthew

How we got here

The earliest attempts to move over to an alternative git forge solution started as early as January 2020. At that time the development work on Pagure became increasingly inconsistent. This resulted in the maintenance costs soaring due to the unmaintained state of the development. Shortly after that, in March 2020, the decision was made to move over to GitLab after evaluating over 300 user stories and a SaaS offering was planned for the Fedora Project. While the development of new features for Pagure slowed down, an exemplary group of contributors stepped up to ensure that the current state of Pagure was maintained well. After a detailed AMA session with folks from GitLab in September 2020, a SaaS offering was announced for Fedora Project in October 2021, and a bunch of sub-projects and SIGs started moving their workflows over to the Fedora Project namespace of GitLab.

While the case looked mostly positive for the sub-projects and SIGs like Fedora Websites and Apps team, there were concerns regarding the scalability in terms of contributor counts and suitability in terms of the Dist Git purposes. This was specifically brought up in the Fedora Council issue ticket discussion and realized at a much later stage in function which led to the initiative request of Dist Git to GitLab from Fedora Infrastructure in February 2023. Fedora Infrastructure worked on an application that helps migrate repositories from Pagure to GitLab through November 2023. By December 2023, the evaluation of Git Forges had become a priority for Fedora Council and a concurrent investigation that explored migrating Dist Git functionality in a forge-agnostic way to another git forge was completed by March 2024.

The Investigation, a.k.a The Prequel!

After the Git Forge alternatives were shortlisted during the Fedora Council F2F Hackfest in February 2024, the Community Linux Engineering (CLE) team (previously called the Community Platform Engineering (CPE) team) were tasked with the investigation. The Advanced Reconnaissance Crew (ARC) sub-team was to report the positives and negatives of each git forge option, while working with various stakeholders across the Fedora Project community to capture the projects requirements for our dist-git. The initiative was led by Tomas Hrcka and Akashdeep Dhar, and Akashdeep also represented the Fedora Councils needs to the team. They began collecting these requirements in the form of user stories in March 2024 to use as the baseline of the investigation. The initiative was then joined by David Kirwan and Ryan Lerch who were able to deploy an instance of both Forgejo and GitLab CE in the CommuniShift app, and the team began validating that each user story worked in each git forge instance. These findings were reported in the official documentation.

The availability of these instances really helped onboard more contributors into the user stories validation efforts. This meant that the focus was not only on the packagers and release engineering workflow but also covered those associated with subprojects/SIGs like Design, Documentation, Accessibility, Websites & Apps, Mindshare etc.

Throughout the investigation, conversations on Fedora Discussion and on the Fedora Project mailing list were happening, making sure Fedoras use cases were being addressed, and the ARC team had presentations during the Fedora Linux 40 Release Party as well as Tomas Hrcka’s talk during the Flock To Fedora 2024 to give this huge change maximum exposure.

Once the investigation completed, Fedora Council was slated to make the final decision on which forge the project would choose to migrate to.

And now the work really begins

Like any other initiative, or large project or piece of work, the plan is never perfect, and this particular effort was quite literally years in the making. The next step for all the parties involved is to have some retrospectives to reflect on how this all went. There are plenty of learnings to be had for sure, and we hope to have a better understanding of how to drive such major decisions in a much better way.

With the investigation on the git forge solutions now wrapped up, we plan to work with Community Linux Engineering (CLE) to direct the migration of Dist Git assets and the conversion of team workflows to the deployed Forgejo Server instance once the decision is formally (and finally!) announced in the coming weeks by Fedora Council.

Pagure Dist Git is connected with a variety of ecosystem services. These include, among others:

Please do not hesitate to reach out to the Fedora Infrastructure team to provide your support. 

Utmost attempts will be made to ensure that the git forge replacement has feature parity with the systems it is attempting to replace (i.e. Pagure Dist Git and Bugzilla). However, it is important to understand that this is a complex undertaking. Most workflows related to various subteams, subprojects and SIGs are likely to remain the same. In some cases we might have to re-imagine the workflows to fit the change (best case scenario). In other cases it may be necessary to deprecate workflows that are no longer reasonably supportable (worst case scenario).

Folks are requested to have an understanding of the user stories that were taken into consideration while comparing the git forge alternatives. Please collaborate with the Fedora Infrastructure team to integrate your specific workflows into the Dist Git Replacement platform.

We look forward to bringing this change to Fedora collaboratively with you in 2025!

The best way to make a decision is to decide

Posted by Ben Cotton on 2024-12-04 13:00:00 UTC

Making decisions in an open source community is hard. Most communities have some sort of consensus model where major decisions require broad support. There’s not just one Big Boss who can come in and unilaterally decide. But sometimes decisions become bogged down in an attempt to get unanimous support or achieve the One Best Decision™. If you’re the person who is supposed to make the decision, make the damn decision.

Consensus is important. People want to feel like their input matters, especially when they’re contributing on a volunteer basis. If participating in your project stops being fun, people will leave. It’s hard to make sustainable progress if you can’t get the majority to go along with you.

But we sometimes overcorrect toward consensus. In those cases, the decision drags on. If a decision is ever made, it no longer has momentum. It might be the most correct decision, but it loses impact because it sits in a state of limbo for months.

In most cases, a good decision made quickly is better than a great decision made slowly. You can iterate on decisions, and that works better with short cycles. The smaller the decision — or the easier it is to reverse — the less time you need to spend building consensus. This is not to say that you should go around making a bunch of decisions on your own. That’s chaos.

Instead, you should have a defined process for how decisions are made: who can gives input, who is empowered to make the decision, and what the time frame looks like. Set a deadline and then make the best decision you can. The process doesn’t have to be complicated — it’s better if the process is simple — it just needs to not catch the community by surprise. Chapter 4 of Program Management for Open Source Projects lays out a framework for building your decision process.

This post’s featured photo by krakenimages on Unsplash

The post The best way to make a decision is to decide appeared first on Duck Alignment Academy.

Upgrade of Copr servers

Posted by Fedora Infrastructure Status on 2024-12-04 09:00:00 UTC

We're updating Copr servers to F41

This outage impacts the copr-frontend and the copr-backend.