We are slowly preparing for Fedora/RISCV (i.e. riscv64) mass rebuild with GCC 14. We already have the initial GCC 14 builds done. For quite some time (multiple Fedora releases) we use the latest available binutils (N) version instead of what’s available general Fedora (N - 1, i.e. one version behind the latest available). After looking at the git log between 2.41 and 2.42 I plan to continue this. @nickc I did a great job already backporting ULEB fix and a workaround from binutils 2.42 to 2.41 in Fedora. Otherwise there are also broken encodings for some T-HEAD extensions (fixed in 2.42), new extensions (e.g. part of RVA23 profile). RVA23 is an important milestone (not yet ratified) as it seems non-ISA specifications for server platform are currently pointing to it as a requirement. RVA24 is expected to become the next major profile.
Technically we should be fine start to start mass rebuild with 2.41 and land 2.42 sometime later after Fedora 40 gets branched. @nickc is usually fast to land a new binutils version after branching.
FYI - I am working on rebasing rawhide binutils to 2.42, but I am going to wait until after the F40 branch before committing my changes. Assuming that nothing goes drastically wrong with my scratch builds however the updated binutils should be available shortly after the branch completes.
Amazing work as usual. Fedora 40 branching is almost here. I assume it’s worth waiting a bit and see it land in dist-git. Just to make sure that NVR has exact same content between two Koji instances.
The only test that appears to have failed is the static analysis test. This is non-voting, so it should not stop the build reaching the buildroot.
The static analysis test had two failures. The ‘unicode’ test is labelled as BAD, but this is a false negative. The unicode test is detecting suspicious unicode characters in the assembler testsuite, but these characters are there expressly to test the assembler’s ability to detect and report suspicious unicode characters…
The annocheck test is failing for the i686 version of addr2line (and probably other i686 binutils executables). This is a known issue with annocheck. Since it was decided a short while ago to build i686 binaries without control flow security enhancements (ie gcc’s --cf-protection option) annocheck has started flagging them up as FAILing to use control flow proctection. This issue took a few iterations of annocheck to fix, but as of version 12.39 annocheck should be properly ignoring this test for i686 binaries.
Oh, and just answer your actual question, I do not think that there is a way to re-spin the tests without creating a new build. But the logs are there. If you click on the “results.json” link near the bottom of the page for the failing test you will find the full output. It is not easy to read, but it is there.