We've established the habit of numbering patches the following way:
0-499: All patches that are unconditionally applied
500-1000: Patches applied under certain conditions (e.g. only on RHEL8)
1500-1599: Patches for LLVM 15
1600-1699: Patches for LLVM 16
1700-1799: Patches for LLVM 17
...
2000-2099: Patches for LLVM 20
The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow
us to "deprecate" a patch instead of deleting it right away.
Suppose llvm upstream in git is at version 20 and there's a patch living
in some PR that has not been merged yet. You can copy that patch and put it
in a line like:
Patch2011: upstream.patch
As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed.
There's no need for you to remove the "Patch2011:" line. In fact, we encourage you
to not remove it for some time. For compat libraries and compat packages we might
still need this patch and so we're applying it automatically for you in those
situations. Remember that a compat library is always at least one major version
behind the latest packaged LLVM version.
I've restored a patch for an older version of LLVM:
We needed to move the
`0001-Always-build-shared-libs-for-LLD.patch`
from the `0-499` range to the `19xx` (current release) and `20xx`
(snapshots) range. In addition the old version of the patch was restored
with the following command and added to the `18xx` range:
```
$ git show
0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch
> 0001-18-Always-build-shared-libs-for-LLD.patch
```
This was needed because the `bundle_compat_lib` (RHEL only) build
condition needs the old version of the patch.
rpminspect now allows to set unicode ignore rules on the dist-git config
Add the known example for misleading bidirectional shipped with
clang-tidy docs here, so we don't need to update the
rpminspect-data-fedora package every single new fedora release.
With the addition of new testplans now we're making the plan result
reporting in bodhi separately (ci.fmf).
Updated the gating acceptance rules to require the two new plans.
lld-alternative is always required. kernel-ark is required only in
rawhide.
With the merge of all the packages into llvm now we need to test
all those with llvm, but the tests are still scattered across different
test repos. This commit adds discover steps to gather all the tests.
Make the following changes:
* Fix a number of `%{?isa}` to use `%{?_isa}` instead.
* Add explicit lld-libs -> llvm-libs and lldb -> clang-libs
dependencies (to satisfy rpminspect rpmdeps analysis).
* Fix libomp-devel -> libomp dependency (it was accidentally
using libomp-devel -> llvm instead).
* Change all `= %{version}` requires to `= %{version}-%{release}`.
We were mostly already doing this, but missed some places.
The scriptlet tried to run llvm-config-%{maj_ver} when upgrading or
downgrading to check if ${maj_ver} has changed. Since postun runs
after the package files have been uninstalled this will always fail
to run the command. We should run instead llvm-config%{exec_suffix},
which in the case of upgrades or downgrades will still be present,
installed from the new package.
Backport patch from https://github.com/llvm/llvm-project/pull/111831
to fix openmp affinity tests on some brew ppc runners.
Also add one more openmp test to the ignore list for s390x.
Also add --time-tests to the lit args -- I had one instance where
openmp tests were running for 4h on s390x. If this happends again,
this should help determine which tests take so much time.
A large number of openmp tests using tsan fail when we hit certain
machines on the rhel8-beefy channel in brew, because they appear
to the use 5-level page tables. This results in memory being
mapped in places where tsan does not expect it.
See https://github.com/llvm/llvm-project/issues/111492 for more
context.
Work around this by disabling the openmp tests that use tsan if
the cpu has the la57 feature.
We currently disable rpath during both build and install. Instead,
we use LD_LIBRARY_PATH to allow the built clang to find the
libLLVM.so etc objects.
However, this does not work well if the system clang and the
clang being built have the same version. During the build, we
use both the system clang and the just-built clang, and they
need to use the system and just-built shared objects respectively.
However, use of LD_LIBRARY_PATH causes us to always use the
just-built objects as long as the versions match.
This is a problem in two scenarios: When building compat packages
for the current system LLVM version, we mix system clang with
compat libraries, which assume different paths. And when building
release candidates, a build using a previous rc of a newer rc
may use ABI-incompatible objects, because we don't version sonames
on rc versions.
Fix this by keeping the rpath during the build and only stripping
it on installation using the CMAKE_SKIP_INSTALL_RPATH option.
For manually installed binaries, we need to also manually strip
the rpath using chrpath.
This way system clang will use system libraries, and just-built
clang will use just-built libraries.
Before we had a very long list of CMake arguments.
There was no room for annotation through comments. Now we have a new
global called `%cmake_config_args` that one can append to.
I've created these `#regions` to group the options for each sub-project:
```
#region clang options
#region compiler-rt options
#region docs options
#region lldb options
#region llvm options
#region openmp options
#region test options
#region misc options
```
This spurious failure has been observed both on aarch64 in fedora
rawhide koji and on ppc64le in c10s koji.
I've filed an upstream issue to track this here:
https://github.com/llvm/llvm-project/issues/111140
Each `#region XY` now has an `#endregion XY` instead of just
`#endregion`. This is optional and `XY` does not have to be repeated for
the "system" to work but it makes working with regions a bit more
convenient.
```
#region globals...
#region packages...
#region prep...
#region build...
#region install...
#region check...
#region misc...
#region files...
#region changelog...
```
The test is run by CI only in rawhide. Requiring it in
all fedora branches will cause that all bodhi updates get
stuck due to the required test being absent.
