#12873 llibcerf update unannounced soname bump and drops s390x
Closed: Fixed with Explanation by orion. Opened by orion.

  • Describe the issue

https://koji.fedoraproject.org/koji/buildinfo?buildID=2789421 is an unannounced soname bump and drops s390x which will break a number of dependencies. Please untag the build.

  • When do you need this? ASAP

  • When is this no longer needed or useful?
    Gets harder to fix after a compose.

  • If we cannot complete your request, what is the impact?
    Will need to rebuild deps, and many will need conditionals to deal with the s390x droppage.

cc @jamatos @junghans @tdawson


Untagged.

Metadata Update from @kevin:
- Issue assigned to kevin
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)
- Issue tagged with: low-trouble, medium-gain

So koschei went briefly green then back to not being able to resolve deps, see https://koschei.fedoraproject.org/package/amanda?collection=f43

Is that just a koschei fluke or a symptom of something else?

Metadata Update from @orion:
- Issue status updated to: Open (was: Closed)

I'm not sure, but that version isn't the latest one in f43:

➜ ~ koji latest-build f43 libcerf
Build Tag Built by


libcerf-2.4-2.fc43 f43 releng

➜ ~ koji buildinfo libcerf-3.1-1.fc43 | grep Tags:
Tags:

Okay - I see what's happened - gnuplot was rebuilt with libcerf 3.1, and now it can't resolve libcerf.so.3. Apparently libcerf is an optional dependency of gnuplot and so it was simply disabled on s390x. So maybe I overreacted?

Not sure what the best course of action is now.

cc @sagitter

The other deps of libcerf are LabPlot and libecpint, and they have not been rebuilt.

LabPlot is already ExcludeArch s390x so I guess no trouble there, as well as libcerf being an optional dep.

libecpint is not excludearch, but looks like libcerf is optional there though.

So if libcerf were to be re-tagged, I could rebuild those two dependencies easily enough.

Or we're going to need to untag gnuplot-6.0.3-3.fc43 as well.

I can rebuild libecpint.

LabPlot takes a while to build ~ 3hours

@junghans this really needed to have been coordinated with the maintainers of the dependent packages and done in a side tag, not thrown out <24 hours before branching and a freeze.

ok, I'll retag it then...

I'll rebuild LabPlot and libecpint with proper conditionals once it's back in the buildroot.

it should be all back

LabPlot - https://koji.fedoraproject.org/koji/taskinfo?taskID=135957156 - conditional is not really needed due to ExcludeArch, but I guess it's pedantically correct should they ever decide to re-enable s390x.

libecpint - https://src.fedoraproject.org/rpms/libecpint/pull-request/2 looks like it fails to build though:

[ 81%] Building CXX object tests/units/multiarr/CMakeFiles/multiarr_test.dir/twoindex.cpp.o
cd /builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/redhat-linux-build/tests/units/multiarr && /usr/bin/g++ -DHAS_PUGIXML -I/builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/include/libecpint -I/builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/include -I/builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/redhat-linux-build/src/../include/libecpint -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c++14 -MD -MT tests/units/multiarr/CMakeFiles/multiarr_test.dir/twoindex.cpp.o -MF CMakeFiles/multiarr_test.dir/twoindex.cpp.o.d -o CMakeFiles/multiarr_test.dir/twoindex.cpp.o -c /builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/tests/units/multiarr/twoindex.cpp
[ 81%] Linking CXX executable test1
cd /builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/redhat-linux-build/tests/lib/int_test1 && /usr/bin/cmake -E cmake_link_script CMakeFiles/test1.dir/link.txt --verbose=1
In file included from /builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/include/generate.hpp:32,
                 from /builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/tests/units/generate/generate.cpp:2:
/builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/include/libecpint/mathutil.hpp: At global scope:
/builddir/build/BUILD/libecpint-1.0.7-build/libecpint-1.0.7/include/libecpint/mathutil.hpp:83:25: warning: libecpint::FAST_POW defined but not used [-Wunused-variable]
   83 |         static double (*FAST_POW[23])(double) {pow_0, pow_1, pow_2, pow_3, pow_4, pow_5,
      |                         ^~~~~~~~
/usr/bin/ld: ../../../src/libecpint.so.1: undefined reference to `dawson(double)'
collect2: error: ld returned 1 exit status

I'll let @junghans clean up that mess from here, I have to go to bed. libecpint seems to impact psi4 and votca,

I have fixed libcerf on s390x in libcerf-3.1-2.fc43

I have fixed libcerf on s390x in libcerf-3.1-2.fc43

Okay. I'm reintegrating libcerf-dependency on s390x in Gluplot (gluplot is a build-required package for OpenMS) .

I should have a fix for libecpint - https://src.fedoraproject.org/rpms/libecpint/pull-request/3 waiting for scratch build

Well, looks like https://bodhi.fedoraproject.org/updates/FEDORA-2025-fad8c5952c may have missed the branch freeze by a few minutes :(. But otherwise everything else is looking good.

Thank you to everyone for your help with this.

@junghans an acknowledgement of and an apology for your mistake here and a thanks to the people who helped clean up from it would be appropriate and much appreciated.

Metadata Update from @orion:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

Sorry for the mess I created! I really appreciate everybody that helped to fix it. I promise to be more careful next time.

Metadata