Fedora Community Blog's avatar

The Fedora Council is pleased to announce that we have chosen Forgejo as the replacement for our git forge! That means you'll see Forgejo powering our package sources (src.fedoraproject.org) as well as our general git forge (what pagure.io is today). It has been a long road to get here, and we cannot thank the Fedora community enough for your patience and support throughout.

For deeper context into what went into this decision, we will walk you through the last few months from the council's perspective. You may want to grab a tea or coffee or beverage - this might be a few paragraphs long

In the beginning

If you'd like to read more about the early stages of this saga, please visit the announcement from two weeks ago. There are lots of helpful links to more documentation about the investigation of both GitLab and Forgejo, as well as more detail about the history of this change.

We have liftoff!

This all officially started after the Council's face-to-face meeting in February 2024. We made a list of all potential replacements for Pagure, including Pagure itself. Over the course of several hours, we ruled out almost all of the candidates, for various reasons, and in the end we were left with Forgejo and GitLab CE (self-hosted). We published a blog post about this, and then got to work figuring out requirements to hand to the team doing this investigation. As Fedora Council is a main governing body of the entire project, we tried to keep the requirements to the project's holistic needs, and not weigh in on too many technical aspects - those would be better reviewed by our community and FESCo. So, with two options to choose from and a list of requirements to investigate them against, we began the formation of the git forge investigation 2024.We just needed the right folks to be part of the investigation team. Enter CLE!

The council made an official request to the Community Linux Engineering team (CLE, which includes the former CPE) to drive an investigation into the two options. The investigation team, ARC ("Advance Recon Crew") launched the investigation in May 2024 with a call to all folks who would be impacted by a change to our current dist-git setup. They asked for use-cases in the form of user stories so they had a better picture of what Fedora needs. Since dist-git has more specific technical demands than general project hosting, the investigation centred around dist-git - we started with the hardest part first!

Throughout 2024, the investigation team promoted awareness of the upcoming change by speaking at Fedora release parties and at Flock, and by the summer they had managed to deploy a test instance of each forge option, to evaluate each use case. The results of that are can be read at the ARC team's read-the-docs page.

Options, so many options!

The Council requested a write up comparing each option. It was sweet to hear that there are no insurmountable 'blockers' for Fedora in terms of technical effort, but also bittersweet as it was going to be harder to make a final decision.

Accessibility

Both projects prioritize accessibility as a core value and implement UI best practices. However, Forgejo faces challenges, as it heavily relies on Fomantic UI, a framework not inherently accessibility-friendly. While Forgejo's upstream, Gitea, applies patches to improve accessibility, significant issues remain that require time and effort to resolve. Accessibility is important to Fedora, and a strategic priority for the Council, and Forgejo lists it as one of their core values, so we hope to collaborate on making this better.

Functionality

In terms of issue tracking, GitLab limits some critical features to premium tiers, while Forgejo offers all functionality without restrictions or fees.

An interesting distinction is syntax highlighting: both solutions leverage the same JavaScript library, but Forgejo uniquely highlights RPM spec files by default.

GitLab supports auto-merging of merge requests, allowing users to define rules for automatic merges once conditions are met. Forgejo lacks this feature. However, its implementation of "actions" is API-compatible with GitHub Actions, enabling potential integration with third-party services or custom pipelines-albeit with significant development effort required.

Maintenance

Forgejo's deployment documentation is relatively sparse, but Codeberg, a reference deployment, successfully supports over 143,000 registered users. The deployment is documented and available in Codeberg Infrastructure repositories (They even use Ansible!). GitLab offers more comprehensive versioned documentation, covering deployment, security, and maintenance. Additionally, GitLab provides an official OpenShift operator for GitLab CE, ensuring seamless container-based deployment.

Contribution

Both GitLab CE and Forgejo operate under the MIT license.

GitLab CE: Actively synchronizes with its proprietary upstream, which is highly active (over 30,000 commits to the main branch in 2024, from 1435 distinct contributors). However, contributions are only accepted for the Enterprise Edition (EE). The official "community fork" has only 5 accepted merge requests ever.

Forgejo: While less active upstream (about 3500 commits in 2024, from 250 contributors), Forgejo and its base, Gitea, accept contributions openly from all users, clearly a more inclusive development process.

Quality (Fedora QA)

By the time Fedora QA were in a position to look into each option for their use cases, the Council had already been trending towards choosing Forgejo. So in an effort to reduce time, we asked the QA team to just look at Forgejo when validating their use cases. QA found the majority of their use cases to be either working or likely working (meaning even though the Forgejo configuration and deployment details are not completely finalized at the moment, and see a path forward for satisfying their needs). However, they did identify several concerning shortcomings in Forgejo's issue tracking features. None of them seem to be a complete blocker, at least from QA perspective, but they are highly-visible regressions and other parties might be affected by them as well, and will need to be prioritized in reconciling them before a migration can happen. Priority will be given to having the ability to move issues between repos to help with debugging, being able to search all of dist-git combined in order to avoid duplication of bugs being reported or opened, and to be able to create private issues in public repositories.

Reaching the decision

After tracking the investigation for months, the Fedora Council had multiple meetings both on Matrix chat and in video conferences to ask questions about each forge and to improve our understanding of just how big this change will be. In one meeting, the council needed to refresh our requirements list to make sure we were asking for the right information at the end of the report. We had initially wanted no recommendation from the investigation team from the report, however as the work continued, it became necessary to change that to needing a recommendation. The investigation team could find no technical blockers to recommend one forge over another, both will require work. This brought about several conversations amongst council members as to whether they already had a preference for one option or the other. It was great conversation and it appeared that once again Forgejo was taking the lead on virtue of their open-source nature. Some of us on the council liked the well documented, and somewhat familiar option of GitLab, but when faced with the reality that sometime in the near future, Fedora may find itself needing to make changes to our git forge, and one option might require money we don't have, or not allow the changes we might need to make, and we did not want to limit the project in any way. And so, Forgejo galloped on down to the finish line!

One pivotal conversation was with the ARC team lead, where they walked the council through a mapping of use cases. This included complexity estimates for the sysadmin and developer work needed to deploy either option.

The diagram shows personas in the project like packagers, developers, etc and how they interact with a git forge in Fedora. The numbers indicate how complex the interaction is with the forge, with 1 being low and 10 being highest. These complexity numbers were determined from lack of documentation on how the services and features work in Fedora. Added caution was used as the team was unfamiliar with how some personas work, and with no documentation to work from….well, best put 10's across the board for some things For others, like packaging, and being a general user of Fedora and other similar personas, because of good documentation available on those workflows, the team felt like they could follow the logic and did not add any complexity number. That is not to say that there won't be any difficulties to overcome when we deploy and begin to use Forgejo for these personas, but I think we can all agree that the complexity can certainly lessen a bit when you have good (or any!) documentation on how something is set up and you feel more confident you can make it work!

After we announced the Council's lean towards Forgejo, we asked the community for one last sanity check on this big decision. Two weeks have passed, and the feedback has been largely positive with no technical objections to this choice. A Council ticket captured: APPROVED by unanimous consensus with no abstentions (+9, 0, 0). Fedora will move to Forgejo!

State of Play

We have made the decision to choose Forgejo, and will look to our community to help plan and execute the migration. The CLE team has already done some investigation into how our dist-git setup works, so if you would like to learn about it you can read the overview here. Please be prepared to see this work happening slowly, and likely across multiple releases. We will continue to focus on dist-git functionality first, and eventually finish with project hosting. This will take time and your patience will be invaluable and greatly appreciated. For right now, a lot of folks are away from their computers to enjoy some time with friends and family so we will start this change in January.

The next chapter

There is a lot still unwritten for Fedora's git forge change. We are only scratching the surface, but we have taken an important step forward - choosing our path. We will have to take our time and break this down into smaller phases so we don't get overwhelmed, so if you're wondering about bugzilla and the project's bug tracking future, don't worry - we are too! We will be exploring that too if not exactly as part of this per se, but rather a logical next step and something we will be keeping in mind. Our focus is to deploy Forgejo, develop the features the project needs to build and release Fedora Linux and function as a project, and replace the existing forges with the new solution.

In January 2025, there will be open meetings happening every Wednesday from January 15th on Matrix. If you would like to be involved with this work, or have any questions, please do join that meeting. The details can be found on the releases calendar in Fedocal. We will also use the tag #git-forge-future when posting on discussion.fpo and we intend to see this plan take the form of an overall change request not tied to any release, with several smaller change requests tied to it which we hope will allow us make this project-wide change in controlled and careful increments.

On behalf of the Fedora Council, I would like to once again thank you all for your contribution to this change, and most importantly to the investigation team who took this on and have done an excellent job reviewing Forgejo for Fedora. I look forward to 2025, it will be a big year!

The post Fedora Chooses Forgejo! appeared first on Fedora Community Blog.

24 Dec 2024 4:31pm GMT

Recently the OpenWrt One was announced for sale. This is a wireless access point/router powered by Banana Pi and designed by the OpenWrt project. Additionally, $10 from every device sold go to the Software freedom conservency to help fund OpenWrt efforts.

The device was available on aliexpress, which is a bit weird for us here in the west, but I had no trouble ordering it there and the cost was pretty reasonable. It arrived last week.

The design is pretty nice. There's a NAND/NOR switch. Normal operation the switch is in NAND setting. If something goes wrong, you can hold down the button on the front while powering on and you shoule get a rescue image. If somehow even that image doesn't work, you can switch the switch to NOR mode and it will boot a full recovery from a USB drive. So, pretty unbrickable.

Initial setup was easy. Just screw on the 3 antenna, connect ethernet and usb-c power and everything came up fine. I was a bit confused on what password to use, but then I realized just hitting return would take me to the 'hey, please set a password' screen. A small note might be nice there.

Since I was using OpenWrt on my existing linksys e8450 it was pretty simple to configure the new accesspoint in a similar manner. Upgrade was pretty easy as soon as I realized that I needed to pick 24.10.0-rcN or snapshot on the firmware selector as there are no stable images for the One yet.

I then spent a lot of time playing with the channel_analysis page. This page scans for other accesspoints and shows you what channels are in heavy use or open. On 5ghz, there was basically nothing else, so no problems there. However, on 2.4Ghz there were an astonishing number of aps. I live out pretty far from town, but there's still a LOT of them. Of course some were coming from 'inside the house' like some roku devices or the like. Finally I decided channel 9 was the best bet.

switching things was a bit of a dance. I connected to the openwrt wireless network, logged in and changed the wired network, then powered off the old ap and swapped the network cable to the new one. Then, rejoined the wireless and changed the name/password so all the existing devices would just keep working.

I do notice faster connection rates on my main laptop at least. The accesspoint is also really responsive either via web (luci) or ssh. I may look at adding some more duties to this device over time. It does have a nvme slot so I could do some caching or perhaps some other setup. I also want to play with the usb-c console port and perhaps at some point upgrade my home switch so I can power it via PoE.

All in all a pretty great device. It seems to currently be sold out, but if you are looking for a nice, unbrickable ap that is very open source, this might just be the ticket for you.

24 Dec 2024 12:20am GMT

Fedora Community Blog's avatar

The Fedora Linux 41 election cycle has ended. We had one group eligible for an election campaign this cycle. Below are the results of the FESCo election, and Mindshare Committee election. Thank you to all who participated, both voters, especially our great candidates and congratulations to the elected members!

FESCo

Five FESCo seats were open this election. A total of 166 voters participated and cast 729 ballots, meaning a candidate could accumulate up to 996 votes.

# Votes	Candidate
709	Kevin Fenzi
527	Zbigniew Jędrzejewski-Szmek
504	David Cantrell
465	Tomáš Hrčka
415	Fabio Alessandro Locati
359	Josh Stone

Mindshare

There were two candidates nominated for the Mindshare Committee, however as Sumantro Mukherjee is already an elected member, there was only one eligible candidate nominated for election. Therefore, Luis Bazan has been automatically re-elected to the Mindshare committee. Congratulations Luis!

The post F41 Election Results appeared first on Fedora Community Blog.

23 Dec 2024 12:54pm GMT

Hello again everyone.

After using wordpress for more than 20 years, I finally decided it was time to move off of it. I'm not really happy about the recent turmoil from the upstream wordpress folks, and I didn't think there was too much value over just moving to a static generator as so many have before me.

I did some looking around, and decided to just go with nikola. It uses python and seems pretty well used. It also has a wordpress import plugin which I hoped to use.

The first problem I ran into is that the 'nikola plugin' command didn't work. I couldn't see that I had done anything to break it, and some poking around let me see that this was a bug in 8.3.0 (which is what the current fedora rpm version is), but was fixed in 8.3.1 (released early this year). There is already a PR to update it:

https://src.fedoraproject.org/rpms/python-nikola/pull-request/6

So, I built the new version locally and plugin was back in business.

The wordpress_import plugin worked somewhat, but there were a few issues I hit there too. It tracebacked if I passed '--one-file' to use the new one file format (instead of a content and a metadata file). I looked at it a bit, but couldn't figure out where it was failing. I did have to tweak a bit of the wordpress export, mostly for mistakes that wordpress ignored, like posts with multiple of the same tag on them, etc.

I looked a bit at comments. I have 81 comments on all my posts over the last 21 years, but there are none in the last 5 years. There is a 'static_comments' plugin that lets you serve the old static comments, which looked promising, but it was not very clear to me how to insert it into the theme I picked to use ('hack'). The doc example has jinja2 examples, and just a 'adjust accordingly for mako templates'. I didn't want to spend a bunch of time learning mako templates, so for now I am just going to drop the comments. If I get time or someone wants to help me get static_comments working, let me know.

Builds are quite fast and it's an easy rsync to my main server. Hopefully this all will make me blog a bit more now.

This post will likely cuse aggregators (like fedoraplanet.org) to see all my recent posts again. Sorry about that.

22 Dec 2024 5:55pm GMT

Fedora Community Blog's avatar

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: 16 - 20 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 51 2024 appeared first on Fedora Community Blog.

20 Dec 2024 10:00am GMT

Fedora Magazine's avatar

Do you use Fedora Server? The Fedora Server Working Group would love to hear from you through our short 10 question survey. Your answers will help us focus our efforts to improve Fedora Server and provide better support for your use cases.

We Have Ideas

The Fedora Server Working Group discusses, plans, and implements the longer-term goals in upcoming releases. We have ideas like a ready-to-use home server appliance image, or special support for VPS/VDS installation in virtual environments, offered by Amazon Lightsail or Contabo. In some systems, the provision of a specially adapted image can greatly simplify operation.

We Need Your Input

Fedora Server's wide use is not sufficiently represented by our small working group. This means your feedback is important. Our current ideas and goals are biased towards our interests and use cases in the Fedora Server Working Group. We can learn from you, users who deploy Fedora Server in a variety of places to meet your unique needs.

Tell Us How You Use Fedora Server

Perhaps you like to spin up multiple instances for short clustered workloads, treating Fedora Server like an unnamed herd of cattle. You might, instead, carefully name your home lab servers after ships from Star Trek or droids from Star Wars. Perhaps treating Fedora Server like beloved family pets. Your small or medium-sized company may run a public website for your Internet presence. You may have deployed Fedora Server as part of a larger server cluster with different operating systems. Each of these scenarios could benefit from specific adjustments to our default Fedora Server Edition. Have you already tweaked your install of Fedora Server? Through this survey, you can bring your experience and expertise to the wider community who loves Fedora Server as much as you do.

We Need Your Feedback

Therefore, no matter how you use Fedora Server, we would love to hear from you. We hope to learn…

Where Fedora Server is deployed?
What are the common use cases for Fedora Server?
What improvements can we make in default packages, documentation, or services for our community?

Go HERE to take the 10 question survey. The Fedora Server Working Group appreciates your time and interest in Fedora Server.

20 Dec 2024 8:00am GMT

RPMs of PHP version 8.4.2 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.15 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.27 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

The packages are available for x86_64 and aarch64.

There is no security fix this month, so no update for version 8.1.31.

PHP version 8.0 has reached its end of life and is no longer maintained by the PHP project.

These versions are also available as Software Collections in the remi-safe repository.

Version announcements:

Installation: use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.4 installation (simplest):

dnf module switch-to php:remi-8.4/common

Parallel installation of version 8.4 as Software Collection

yum install php84

Replacement of default PHP by version 8.3 installation (simplest):

dnf module switch-to php:remi-8.3/common

Parallel installation of version 8.3 as Software Collection

yum install php83

Replacement of default PHP by version 8.2 installation (simplest):

dnf module switch-to php:remi-8.2/common

Parallel installation of version 8.2 as Software Collection

yum install php82

And soon in the official updates:

Fedora Rawhide now has PHP version 8.4.2
Fedora 41 - PHP 8.3.15
Fedora 40 - PHP 8.3.15

To be noticed :

EL-10 RPMs are built using RHEL-10.0-beta
EL-9 RPMs are built using RHEL-9.5
EL-8 RPMs are built using RHEL-8.10
intl extension now uses libicu74 (version 74.2)
mbstring extension (EL builds) now uses oniguruma5php (version 6.9.9, instead of the outdated system library)
oci8 extension now uses the RPM of Oracle Instant Client version 23.6 on x86_64, 19.25 on aarch64
a lot of extensions are also available, see the PHP extensions RPM status (from PECL and other sources) page

Information:

Base packages (php)

Software Collections (php81 / php82 / php83)

20 Dec 2024 5:26am GMT

Moderation tools are an important part of managing any online community, but the tools aren't always up to snuff. "Moderation tools" can cover many different features; in this post, I'm specifically talking about queues where messages are held for moderator action.

There are two main reasons you'd use a moderation queue. The first is to restrict incoming messages on an announcement-only list. You want to keep them low-traffic so that people will stay subscribed. This reason is focused on addressing merely-annoying behavior. The second is to ensure a particular message is appropriate. This might be implemented as "hold all messages from a particular user" or a flag system for moderators to review a specific post after it is sent. In either case, the second reason is focused on addressing abusive behavior.

Regardless of the motivation, the moderation queue is essential the same: a message is held until someone comes along and makes a decision about it. Where many tools miss the mark is in cooperation. Any community of more than trivial size should have multiple moderators. These moderators probably overlap in the time they spend moderating. But most tools I've used don't have a great in-band way to coordinate.

The inspiration for this post comes from a handful of times where I, as one of the moderators of an announcement mailing list in Fedora, released a message that had been intentionally left held. There was no good way to notify the other moderators that this message was still held on purpose, and certainly no indication in the Mailman web interface. So I let the messages fly. That was mostly fine - the messages were supposed to be released eventually, just not quite yet.

In the abuse-focused case, a moderator might be looking into the poster's history, or asking follow up questions of someone before they choose to act on the message. Or maybe they want to talk to some other moderators for a second opinion. Without a clear indication that the message is being worked on, another moderator may come in and act on it.

So if you're designing a tool that includes a moderation queue, please make sure it supports an indication that the message is acknowledged. Ideally, include a field to indicate why it is still in-progress.

This post's featured photo by Dim Hou on Unsplash.

The post Moderation queues need context appeared first on Duck Alignment Academy.

18 Dec 2024 1:00pm GMT

Here is a quick howto upgrade default PHP version provided on Fedora, RHEL, CentOS, AlmaLinux, Rocky Linux or other clones with latest version 8.4.

You can also follow the Wizard instructions.

Architectures:

The repository is available for x86_64 (Intel/AMD) and aarch64 (ARM).

Repositories configuration:

On Fedora, standards repositories are enough, on Enterprise Linux (RHEL, CentOS) the Extra Packages for Enterprise Linux (EPEL) and Code Ready Builder (CRB) repositories must be configured.

Fedora 41

dnf install https://rpms.remirepo.net/fedora/remi-release-41.rpm

Fedora 40

dnf install https://rpms.remirepo.net/fedora/remi-release-40.rpm

RHEL version 10.0-Beta

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-10.rpm
subscription-manager repos --enable codeready-builder-for-rhel-10-x86_64-rpms

RHEL version 9.5

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms

RHEL version 8.10

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms

CentOS Stream 10

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-10.rpm
crb install

Alma, CentOS Stream, Rocky version 9

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
crb install

Alma, Rocky version 8

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
crb install

PHP module usage

With Fedora and EL, you can simply use the remi-8.4 stream of the php module

With Fedora 41 (dnf5 has partial module support)

dnf module reset php
dnf module enable php:remi-8.4
dnf install php-cli php-fpm php-mbstring php-xml

Other distributions (dnf4)

dnf module switch-to php:remi-8.4/common

PHP upgrade

By choice, the packages have the same name as in the distribution, so a simple update is enough:

dnf update

That's all :)

$ php -v
PHP 8.4.2 (cli) (built: Dec 17 2024 15:31:31) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Remi's RPM repository  #StandWithUkraine
Zend Engine v4.4.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.2, Copyright (c), by Zend Technologies

Known issues

The upgrade can fail (by design) when some installed extensions are not yet compatible with PHP 8.4.

See the compatibility tracking list: PECL extensions RPM status

If these extensions are not mandatory, you can remove them before the upgrade, otherwise, you must be patient.

Warning: some extensions are still under development, but it seems useful to provide them to upgrade more people and allow users to give feedback to the authors.

More information

If you prefer to install PHP 8.4 beside the default PHP version, this can be achieved using the php84 prefixed packages, see the PHP 8.4 as Software Collection post.

You can also try the configuration wizard.

The packages available in the repository were used as sources for Fedora 42.

By providing a full feature PHP stack, with about 150 available extensions, 11 PHP versions, as base and SCL packages, for Fedora and Enterprise Linux, and with 300 000 downloads per day, the remi repository became in the last 19 years a reference for PHP users on RPM based distributions, maintained by an active contributor to the projects (Fedora, PHP, PECL...).

Fedora Linux 42

A.K.A, the answer to life, the universe and everything. Below are some changes currently in review by our community, and some that are now with FESCo for voting.

Announced Change Proposals
Change Proposals awaiting FESCo decision

Our Change Set page has a list of the currently accepted changes, and below are a list of some key dates:

December 18th - Changes requiring infrastructure changes
December 24th - Changes requiring mass rebuild
December 24th - System Wide changes
January 14th - Self Contained changes
February 4th - Changes need to be Testable
February 4th - Branching
February 18th - Changes need to be Complete

Be sure to keep an eye on the Fedora Linux 42 release schedule, and our Fedora Linux 43 and Fedora Linux 44 are now live also.

Hot Topics

Elections

The F41 elections is live, and we have one election currently running. The Fedora Engineering Steering Committee (FESCo) has five (5) open seats, and you can vote for the candidates up for election by visiting the elections app. The voting period will close on Friday 20th December @ 23:59:59 UTC and the results of the election will be announced on Monday 23rd December.

The candidates up for the FESCo election are:

Git Forge Update - Fedora Moves Towards Forgejo

The Fedora council have released an announcement on the intention to go with Forgejo for the projects git forge option in 2025 in the Fedora Magazine. Before the decision is made though, there is a last call for feedback - the council believe this is the right choice, and we have been working with the investigation team and doing our own due diligence, but if there is a reason we should not choose forgejo, please let us know on this feedback thread before Wednesday 18th December. The council will put this decision to a formal vote on this date.

If Forgejo is voted by council as the path forward, you can expect a more in depth announcement on how we reached this decision, and an overview of what features we will need to develop, what ones we will be able to make use of immediately, and a call to arms for those who would like to take an active part in this very big change in 2025.

New Btrfs SIG

A new Btrfs sig has been formed in Fedora! If you would like to take part, or find out more about the work this group will do/is doing, check out their announcement on the devel-announce mailing list.

Boot-C

For all things happening in boot-c this week in Fedora, be sure to read their most recent post, and for all the updates on boot-c in Fedora, use the #bootc-initiative tag on discussion.fpo.

Reminders

FOSDEM Travel

If you are traveling to FOSDEM and would like to connect with others from the project who will be there too, please add your details to the event sheet.

'Shutdown' Period

Just a reminder that we are heading into what is known to some as the 'shutdown' period. A lot of folks around the project are either already, or soon to be, enjoying some well deserved time away from the computers, or at the very least some reduced time Please be mindful that your messages and tickets may go unanswered for the next few weeks, and I would suggest re-pinging or re-commenting in early January. Infra will be monitored, but only serious requests, eg ones that are going to bring the whole project to a stop, are likely to get immediate attention.

The post Fedora Operations Architect Report appeared first on Fedora Community Blog.

16 Dec 2024 9:29pm GMT

15 Dec 2024 6:16am GMT

14 Dec 2024 11:17am GMT

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

13 Dec 2024 12:15pm GMT

Fedora Community Blog's avatar

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.

13 Dec 2024 10:00am GMT

fidzu : Fedora

24 Dec 2024

In the beginning

We have liftoff!

Options, so many options!

Accessibility

Functionality

Maintenance

Contribution

Quality (Fedora QA)

Reaching the decision

State of Play

The next chapter

23 Dec 2024

FESCo

Mindshare

22 Dec 2024

20 Dec 2024

Infrastructure & Release Engineering

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

We Have Ideas

We Need Your Input

Tell Us How You Use Fedora Server

We Need Your Feedback

18 Dec 2024

Architectures:

Repositories configuration:

Fedora 41

Fedora 40

RHEL version 10.0-Beta

RHEL version 9.5

RHEL version 8.10

CentOS Stream 10

Alma, CentOS Stream, Rocky version 9

Alma, Rocky version 8

PHP module usage

PHP upgrade

Known issues

More information

17 Dec 2024

16 Dec 2024

Fedora Linux 42

Hot Topics

Elections

Git Forge Update - Fedora Moves Towards Forgejo

New Btrfs SIG

Boot-C

Reminders

FOSDEM Travel

'Shutdown' Period

15 Dec 2024

14 Dec 2024

13 Dec 2024

Infrastructure & Release Engineering

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

fidzu channels