Why is Fedora 40 so far back on pipewire and dnf5?

I have been monitoriing the pipewire package and dnf5,
the ones in the updates repo for Fedora 40 are way behind

pipewire  1.0.7-2
dnf5      5.1.17-1

But the tags for dnf5 for examples are way up in 5.2.x:

refs/tags/5.2.4.0 Wed Jun 26 18:10:20 2024 +0000 Release 5.2.4.0
refs/tags/5.2.3.0 Mon Jun 3 14:14:48 2024 +0000 Release 5.2.3.0
refs/tags/5.2.2.0 Tue May 28 11:55:05 2024 +0000 Release 5.2.2.0
refs/tags/5.2.1.0 Mon May 6 08:15:47 2024 +0000 Release 5.2.1.0
refs/tags/5.2.0.0 Wed Apr 24 14:11:26 2024 +0000 Release 5.2.0.0
refs/tags/5.1.17 Wed Apr 3 08:52:44 2024 +0000 Release 5.1.17
refs/tags/5.1.16 Tue Apr 2 09:57:08 2024 +0000 Release 5.1.16
refs/tags/5.1.15 Fri Mar 15 12:23:35 2024 +0000 Release 5.1.15
refs/tags/5.1.14 Tue Mar 5 12:27:37 2024 +0000 Release 5.1.14
refs/tags/5.1.13 Tue Feb 20 14:31:30 2024 +0000 Release 5.1.13

Similarly for pipewire the tags are:

refs/tags/1.2.1 Fri Jul 12 09:24:23 2024 +0200 1.2.1
refs/tags/1.2.0 Thu Jun 27 15:31:45 2024 +0200 1.2
refs/tags/1.1.83 Tue Jun 18 12:47:40 2024 +0200 1.1.83
refs/tags/1.1.82 Fri May 24 11:48:53 2024 +0200 1.1.82
refs/tags/1.0.7 Fri May 24 11:12:36 2024 +0200 1.0.7
refs/tags/1.1.81 Thu May 16 10:25:45 2024 +0200 1.1.81

So I suspect what’s going on is those packages have certain target versions that will be stable and then pushed to Fedora 40. So when to expect or what would those versions be?

1 Like

dnf5 wasn’t complete (and still isn’t) when f40 was released.

It may come with f41.

https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5

https://fedoraproject.org/wiki/Changes/SwitchToDnf5

2 Likes

The latest version of both packages are now being tested in rawhide aka Fedora41.

The latest dnf5 build is here

The latest pipewire build is here

Added dnf5

dnf5 wasn’t complete (and still isn’t) when f40 was released.

That has nothing to do with the question, dnf5 is in the official Fedora 40 repos (see below) and I know the limitations of it and prefer to use dnf5 (or at least have it installed so it’s an option to use).

dnf info --available dnf5

Name : dnf5
Epoch : 0
Version : 5.1.17
Release : 1.fc40
Architecture : x86_64
Download size : 700.6 KiB
Installed size : 1.7 MiB
Source : dnf5-5.1.17-1.fc40.src.rpm
Repository : updates
Summary : Command-line package manager
URL : GitHub - rpm-software-management/dnf5: Next-generation RPM package management system
License : GPL-2.0-or-later
Description : DNF5 is a command-line package manager that automates the process of installing,
: upgrading, configuring, and removing computer programs in a consistent manner.
: It supports RPM packages, modulemd modules, and comps groups & environments.
Vendor : Fedora Project

In my opinion, if dnf5 is in the official Fedora 40 repos then it’s good enough to use or it wouldn’t be there.

The latest version of both packages are now being tested in rawhide aka Fedora41.

Again that’s not the question, I know FC41 had the newer packages for both, I mean on Fedora 40 can we expect a pipewire update to 1.2.x ? I don’t want to use the pipewire from fc41 because pipewire is an entire ecosystem of packages that are related:

pipewire-codec-aptx-1.0.7-1.fc40.x86_64
pipewire-libs-1.0.7-2.fc40.x86_64
pipewire-1.0.7-2.fc40.x86_64
pipewire-jack-audio-connection-kit-libs-1.0.7-2.fc40.x86_64
pipewire-jack-audio-connection-kit-1.0.7-2.fc40.x86_64
pipewire-plugin-libcamera-1.0.7-2.fc40.x86_64
pipewire-utils-1.0.7-2.fc40.x86_64
pipewire-pulseaudio-1.0.7-2.fc40.x86_64
pipewire-gstreamer-1.0.7-2.fc40.x86_64
pipewire-alsa-1.0.7-2.fc40.x86_64
pipewire-doc-1.0.7-2.fc40.x86_64

all those package have version 1.0.7 in their names for a reason.
I don’t want to jury rig in “pipewire” 1.2.1 from FC41 with my existing 1.0.7 packages. I could jam all dozen of those pipewire packages from pipewire-1.2.1-2.fc41 | Build Info | koji but I’d rather not, it seems like a bunch of hacking of my system.

I wrote a bug against plasmashell with Pipewire 1.0.7 in use and would be interested to try a newer pipewire to see if it fixes the bug:

https://bugs.kde.org/show_bug.cgi?id=486272

I suppose I could just put in pipewire 1.2.1.fc41 on for a short time, test the bug, then swap it back to 1.0.7

I was able to make a script to get all those packages, then I upgraded to those, did the test and showed the bug is still there. Used “dnf install ./pipewire*1.0.7*rpm” to install back to the old 1.0.7 files (I’d used the script to get all the files in the local folder)

Thanks

Again, read @vgaetera post, second post of this topic. It links to the update policy which is being implemented: no major updates within one release. Big update → next release.

for reference, landing pages for both packages:

2 Likes

Well, okay I looked at that “updates policy” but it doesn’t seem very sensible to me, Fedora 40 is on pipewire 1.0.7 and the new pipewire is 1.2.1 in Fedora 41. So that’s hardly a “big release” since they’re both in the same major version. Maybe the version numbers in pipewire to completely ad hoc and 1.0.7 to 1.2.1 is a huge change.
I went ahead and upgraded my test Fedora 40 from pipewire 1.0.7 to 1.2.1-2 and wireplumber to 0.5.5 (whatever was on Fedora FC41). I used “dnf upgrade --releasever=41 …” to full them from the FC41 repos.
They worked just fine as is but didn’t fix the Bug 486272 I reported to bugzilla.
So basically it doesn’t matter anyway and I’ll have to put up with the bug until FC41 probably fixes it. 486272 might be a quirk of AMD laptops because I have a Intel Dell that doesn’t do the weird thing with headsets as described in my bug.
Thanks

You can check out the PipeWire Releases page and look at the changes implemented between 1.0.7 and 1.2.1 to see if they would generally be considered big/major - I’d argue they are.

Keep in mind how long PipeWire was on versions beginning with 0.x, and the amount of major work that happened during that time…and keep in mind that a whole heck of a lot of software doesn’t truly follow the semantic versioning prescriptions, including the Linux kernel itself!

1 Like