Fix Fedora 40 Ci Bugs

[lukewarmtemp]

Fix Fedora 40 CI bugs

[jmarrero]

We probably need to do this again too:
https://github.com/coreos/rpm-ostree/pull/4570/files

I will attempt to continue with this PR changes later today.

[jmarrero]

We are building on:
registry.ci.openshift.org/coreos/fcos-buildroot:testing-devel which currently is f40 we save the rpm-ostree binary on a tar (install.tar)

then run the tests against:
registry.ci.openshift.org/coreos/coreos-assembler:latest which is f39

the `/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found`

I think this is telling us that the version of libstdc++ from f40 are not backward compatible... trying to replicate locally.

[jlebon]

coreos/coreos-assembler#3785 should help

[jlebon]

Note we usually also bump the compose commit we test with. At some point those RPMs will be GC'ed.

rpm-ostree/tests/compose.sh

Line 6 in e0cf3f7

FEDORA_COREOS_CONFIG_COMMIT=ce65013fcb9f10bfee1c7c1c27477c6c6ce676b3

[cgwalters]

Thanks for working on this, it's a fire drill every time...

[jmarrero]

something is odd with the f40 container, Colin hit this in ostree too: ostreedev/ostree#3237 (comment)
For us that is the failure we see on: https://github.com/coreos/rpm-ostree/blob/main/rust/src/client.rs#L360C1-L362C6

[cgwalters]

OK I added a fix for the container one, and also squashed the changes together with a bit more informative commit message hopefully.

(For example previously we were saying "Fix Fedora 40 CI compiler bug" but I don't think it's a compiler bug, just clang changed to be more picky about what it accepts for a legitimate reason)

[cgwalters]

OK next up is

(rpm-ostree compose tree:131951): libdnf-CRITICAL **: 17:28:49.649: Detection of Platform Module failed: No valid Platform ID detected

OK right...I think we need to turn off modularity.

[cgwalters]

OK I tried a smaller subset of dropping the modularity stuff but...there's also the dracut failure which looks possibly legitimate.

[cgwalters]

@lukewarmtemp I'm getting pulled into other things, can I toss this 🏈 back to you to?

already fixed on current commit.

[jmarrero]

down to one...

tests/vmcheck/test-layering-scripts.sh

for combo in ${license_combos}; do
    vm_cmd cat /usr/share/transfiletriggerin-license-${combo}.txt > transfiletriggerin-license-${combo}.txt
    rm -f transfiletriggerin-fs-${combo}.txt.tmp
    (for path in $(echo ${combo} | sed -e 's,-, ,g'); do
         vm_cmd find /usr/share/licenses/${path} -type f
     done) | sort > transfiletriggerin-fs-license-${combo}.txt
    diff -u transfiletriggerin-license-${combo}.txt transfiletriggerin-fs-license-${combo}.txt
done

that find is failing:

[2024-05-03T16:34:22.682Z]    layering-scripts: + ssh -o User=root -o ControlMaster=auto -o ControlPath=/dev/shm/ssh-vmcheck-1714753744750736964.sock -o ControlPersist=yes -F /tmp/test.o4Tcc6/ssh-config vmcheck find /usr/share/licenses/zlib -type f
[2024-05-03T16:34:22.682Z]    layering-scripts: find: ���/usr/share/licenses/zlib���: No such file or directory

I wonder if the file is not there in a new package version or if those non ASCII (maybe) characters might be the issue.

[jmarrero]

probably this: https://fedoraproject.org/wiki/Changes/ZlibNGTransition#:~:text=Zlib%20has%20long%20served%20as,with%20existing%20packages%20and%20libraries.

[cgwalters]

Yeah looks like that code needs to use /usr/share/licenses/zlib-ng instead of /usr/share/licenses/zlib

[jlebon]

Oddly, zlib-ng doesn't ship a license file. Anyway, I've updated it to use which. That bit of the test passes locally for me on f40.

[jmarrero]

lgtm 🙏 🚀