Tested with

[lrineau@fernand]~/tmp% koji download-build 2583907
Downloading [1/3]: tracer-1.2-1.fc41.src.rpm
[====================================] 100% 103.43 KiB / 103.43 KiB
Downloading [2/3]: tracer-common-1.2-1.fc41.noarch.rpm
[====================================] 100% 21.55 KiB / 21.55 KiB
Downloading [3/3]: python3-tracer-1.2-1.fc41.noarch.rpm
[====================================] 100% 138.06 KiB / 138.06 KiB
[lrineau@fernand]~/tmp% sudo dnf update ./tracer-common-1.2-1.fc41.noarch.rpm ./python3-tracer-1.2-1.fc41.noarch.rpm 
Updating and loading repositories:
[...]

It worked well. Thanks for the update, Jakub!

New upstream release: CGAL version 5.6.2.

@jwakely Is building CGAL in the side tag sufficient? Don't you have to add it to this update as well?

You forgot to build CGAL in this side tag. CGAL is header-only, and thus does not produce any binary depending on boost, but its build has a test that tries to build an actual binary from CGAL. During the mass-rebuild for F40, CGAL failed to build because of boost-1.81 being incompatible with gcc-14 (something in boost-math about __float128). I have verified with toolbox that locally CGAL can be build and used with this update. And now I have triggered a new build of CGAL hijacking your side tag f40-build-side-81691. It built fine. It is too late to add that build to this update? Otherwise I will create another update with bodhi, once this one is in stable.

(After the restart, the running, and working, version, was containerd-1.6.23-2.fc39. Sorry for the various typos in my previous message.)

After the upgrade to containerd-1.6.23-2.fc39:

[lrineau@fernand]~% docker run fedora echo OK                                       
docker: Error response from daemon: failed to create task for container: failed to create shim task: ttrpc: cannot marshal unknown type: *task.CreateTaskRequest: unknown.
ERRO[0000] error waiting for container:                 
[lrineau@fernand]~% sudo systemctl restart docker                                   
[lrineau@fernand]~% docker run fedora echo OK    
OK

So: - before the restart, it was version 1.6.23-1.fc39 and it failed, - after the restart, with version 1.6.23-1.fc39, docker run fedora echo OK works.

Thanks for the update!

I got an error during a dnf update:

Running transaction

Transaction failed: Rpm transaction failed.
  - libfabric.so.1()(64bit) is needed by openmpi-4.1.4-9.fc38.x86_64
  - libfabric.so.1(FABRIC_1.0)(64bit) is needed by openmpi-4.1.4-9.fc38.x86_64
  - libfabric.so.1(FABRIC_1.1)(64bit) is needed by openmpi-4.1.4-9.fc38.x86_64
  - libfabric.so.1(FABRIC_1.3)(64bit) is needed by openmpi-4.1.4-9.fc38.x86_64
  - libfabric.so.1(FABRIC_1.5)(64bit) is needed by openmpi-4.1.4-9.fc38.x86_64

(same issue with both dnf4 and dnf5).

A manual installation of libfabric solved the issue:

sudo dnf install /usr/lib64/libfabric.so.1

And after that the dnf update managed to update:

Running transaction
[1/8] Verify package files                                                                                                                                                  100% | 230.0   B/s |   3.0   B |  00m00s
[2/8] Prepare transaction                                                                                                                                                   100% |   9.0   B/s |   6.0   B |  00m01s
[3/8] Upgrading openmpi-0:4.1.4-9.fc38.x86_64                                                                                                                               100% |  51.6 MiB/s |  10.0 MiB |  00m00s
[4/8] Upgrading openmpi-devel-0:4.1.4-9.fc38.x86_64                                                                                                                         100% |   8.6 MiB/s |   2.0 MiB |  00m00s
[5/8] Upgrading python3-openmpi-0:4.1.4-9.fc38.x86_64                                                                                                                       100% |  87.9 KiB/s | 540.0   B |  00m00s
[6/8] Erasing openmpi-devel-0:4.1.4-8.fc38.x86_64                                                                                                                           100% |  92.0 KiB/s | 848.0   B |  00m00s
[7/8] Erasing python3-openmpi-0:4.1.4-8.fc38.x86_64                                                                                                                         100% | 400.0   B/s |   2.0   B |  00m00s
[8/8] Erasing openmpi-0:4.1.4-8.fc38.x86_64                                                                                                                                 100% | 812.0   B/s | 559.0   B |  00m01s
>>> Running trigger-install scriptlet: glibc-common-0:2.37-5.fc38.x86_64
>>> Stop trigger-install scriptlet: glibc-common-0:2.37-5.fc38.x86_64
>>> Running trigger-install scriptlet: man-db-0:2.11.2-2.fc38.x86_64
>>> Stop trigger-install scriptlet: man-db-0:2.11.2-2.fc38.x86_64
>>> Running trigger-post-uninstall scriptlet: man-db-0:2.11.2-2.fc38.x86_64
>>> Stop trigger-post-uninstall scriptlet: man-db-0:2.11.2-2.fc38.x86_64

ipe no longer crashes at startup

That update works.

Note that the clang compiler version 10.0.0, using llvm 10.0.1 from FEDORA-2020-e50fd340c1 is broken without this update: it miscompiles my programs.

About the ABI change detected by the taskotron: the two functions CORE::BigRat CORE::operator/(const CORE::BigRat&, const CORE::BigRat&) and CORE::BigRat CORE::div_exact(const CORE::BigRat&, const CORE::BigRat&)are inline, so the ABI change cannot have an effect.

If you don't mind, yes, I would push to stable.

@churchyard: could it be that, by editing the update, you became the sole "owner" of it, even if the bodhi UI still mention only me?

Sorry for my empty comment. I no longer see anything in the Bodhi web UI that would allow me to request the push to stable, or to edit the update. What am I missing?

This update will have to wait for depending package to be rebuilt against it...

@dmossor: Do you have a bugzilla entry for that SELinux bug?

/usr/libexec/kscreenlocker_greet now works for me, with this update. I used this F25 build even though I run F24.