Bug 2284124

Reported upstream: https://gitlab.kitware.com/cmake/cmake/-/issues/26021

cmake upstream report is a bit premature, we'll need to look at the case first and decide what (if anything) to do about it on the rpm front. That'll have to wait over the weekend though.

If the issue is within https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Internal/CPack/CPackRPM.cmake I think it's quite feasible to patch it upstream and assume that cmake and rpm versions are built for the current running system (excluding maybe installing rpm from pip). Either way we would probably want upstream to have a check for RPM 4.20 and gradually migrate the support?

Hold your horses, please.

Before jumping to conclusions we'll need to investigate what exactly cpack is doing here. If it does what I think it does, it does fall into the category of 4.20 stuff failing because they're trying to herd rpm from the outside instead of using it from the inside, BUT. This is a different case from various other 4.20 "regressions" people have run into due to creative packaging, hardcoded assumptions and whanot, in that cpack is using a documented long-standing command line switch that was suddenly removed. We may well have to backpedal on this one, at least for the time being, and look to solve cpack's use-case in a different manner long-term.

We'll look into this on Monday.

As expressed in https://gitlab.kitware.com/cmake/cmake/-/issues/26021#note_1530422:

We can't break cpack like this, so we'll bring back --buildroot for the time being and investigate better alternatives for the future later on. I'll try to get this sorted ASAP, hopefully today.

There seems to be more issues, not too surprisingly due to the changes to debuginfo enablement. 

The plan there was to enable debuginfo on packages without requiring use of %setup, but there are just too many things this breaks, one of them again cpack. So we'll bring back the requirement of %{buildsubdir} being defined for the debuginfo machinery to fire.

This should be fixed as of 4.19.91-7, I got a successful scratch-build of cmake here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=118548810

Launched a full build just now: https://koji.fedoraproject.org/koji/taskinfo?taskID=118549531

On a related note, while looking at this I spotted the following in cmake.spec:

# Failing for rpm 4.19
NO_TEST="$NO_TEST|CPackComponentsForAll-RPM-default"
NO_TEST="$NO_TEST|CPackComponentsForAll-RPM-OnePackPerGroup"
NO_TEST="$NO_TEST|CPackComponentsForAll-RPM-AllInOne"

Coming from https://src.fedoraproject.org/rpms/cmake/c/ae71be464b559997355261bd60fe5098b149674d?branch=rawhide

There was never any bug filed for this so we've had no idea.

The build succeeds now alright, there's just one gating failure (https://bodhi.fedoraproject.org/updates/FEDORA-2024-c3ee74a980 / https://artifacts.dev.testing-farm.io/0bed7031-113e-4950-9594-48a79d86daf3/)

Looking at https://artifacts.dev.testing-farm.io/0bed7031-113e-4950-9594-48a79d86daf3/work-ciggtpoy6f/plans/ci/execute/data/guest/default-0/tests/cmake-testsuite-sanity-1/output.txt I see this:

:: [ 11:18:52 ] :: [   PASS   ] :: Command 'rpm -D "_topdir /tmp/tmp.jLYNZj026K" -U *.src.rpm' (Expected 0, got 0)
:: [ 11:19:19 ] :: [   PASS   ] :: Command 'dnf builddep -y /tmp/tmp.jLYNZj026K/SPECS/*.spec' (Expected 0, got 0)
:: [ 11:19:20 ] :: [   PASS   ] :: Command 'su -c 'rpmbuild -D "_topdir /tmp/tmp.jLYNZj026K" -bp /tmp/tmp.jLYNZj026K/SPECS/*.spec &>/tmp/tmp.jLYNZj026K/rpmbuild.log' cmkbld' (Expected 0, got 0)
:: [ 11:19:20 ] :: [   INFO   ] :: Sending /tmp/tmp.jLYNZj026K/rpmbuild.log as tmp-tmp.jLYNZj026K-rpmbuild.log
:: [ 11:19:20 ] :: [   PASS   ] :: Command 'rlFileSubmit /tmp/tmp.jLYNZj026K/rpmbuild.log' (Expected 0, got 0)
:: [ 11:19:20 ] :: [   PASS   ] :: Command 'CMakeDir=' (Expected 0, got 0)
:: [ 11:19:20 ] :: [   PASS   ] :: Command 'cd /tmp/tmp.jLYNZj026K/BUILD/' (Expected 0, got 0)
:: [ 11:19:20 ] :: [   FAIL   ] :: Command 'su -c './bootstrap &>/tmp/tmp.jLYNZj026K/bootstrap.log' cmkbld' (Expected 0, got 127)

The fundamental issue here is assuming rpmbuild puts things into certain places just the way it always did, and doing stuff from outside the spec. Which is certain to run into trouble now.

This test builds cmake again from the rpm prepped sources, but then manually runs (or, tries to) a ./bootstrap build from the patched source, and I guess, test that? Maybe I'm just missing something here, but this seems not only extremely expensive but also a bizarre way to test the cmake package we just built, because the re-bootstrapped build is not going to be built with the same exact environment as the package just built, that we're supposed to be testing here.

If the point is to ensure the just-built cmake can be built again, then why not just run the full rpmbuild and its checks on it? But, like said this seems like an extremely expensive test to be doing.

Anyway, this is now outside what I can fix in rpm, so reassigning to cmake.

Oh and, one way to preserve such a test relying on external access to rpm prepared source is just look it up, eg in the context of the test, something like (untested):

rlRun "builddir=$(dirname $(find $TmpDir/ -name bootstrap))"

That said, this kind of usage is a far more common theme than I ever imagined, so maybe rpm should export the build directory information somehow. A simple way would be explicitly outputting the build directory in a parseable form at the point rpm itself knows the directory during the build.

We knew about the failure when we merged the PR, I am going to wave it.

Correction, we knew about *a* CI failure, not about this one. Doing it anyway.

Thanks for the fix.

I have opened a separate issue for tracking the tmt test refactoring: https://bugzilla.redhat.com/show_bug.cgi?id=2290539
If anyone has some feedback on what tests should be added, please let me know and I'll try to design some.

W.r.t. the cpack tests here, I don't think there is much special case to be designed other than calling the bundled ctest testuite.