Comments

29 Comments

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

karma

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.

BZ#2036372 Update tbb to latest release

(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!

BZ#2237396 Failed to create task for container: failed to create shim task: ttrpc: cannot marshal unknown type: *task.CreateTaskRequest: unknown

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
User Icon rineau commented & provided feedback on ipe-7.2.24-5.fc36 a year ago
karma

ipe no longer crashes at startup

BZ#2088015 ipe crashes on startup
karma

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.

BZ#1836114 tracer -it produces python traceback "AttributeError: 'str' object has no attribute 'decode'"
BZ#1841460 [abrt] python3-tracer: _load_package_info_from_hdr(): rpm.py:201:_load_package_info_from_hdr:AttributeError: 'str' object has no attribute 'decode'

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?

karma

@frostyx I do not understand why you allowed that update to be pushed to F24 stable updates.

  • the QA automated tests failed: the upgrade path from F24 to F25 is broken (you need to push recent versions of tracer to F25 before you push them to F24),

  • the bug #1402520 should have been a blocker: I can no longer use tracer on my desktop machine.

... Well, that may be also my fault: I should have tested the update before the period of 7 days.

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