Before when running one of the following targets it could be that there were multiple run files in `/var/lib/mock/$(MOCK_CHROOT)/root/var/tmp`.
```
edit-last-failing-script - Opens the last failing or running script from mock in your editor
of choice for you to edit it and later re-run it in mock with:
"make mockbuild-rerun-last-script-...".
mockbuild-rerun-last-script - Re-runs the last failing or running script of your release/mock mockbuild.
```
The function to edit the last one that was run sometimes picked the wrong file. Now we sort the files in there aforementioned directory before editing or running it again.
+ /usr/lib/rpm/redhat/brp-fix-pyc-reproducibility /builddir/build/BUILDROOT/llvm19-19.1.3-4.fc40.x86_64/usr/lib/python3.12/site-packages
find: ‘/builddir/build/BUILDROOT/llvm19-19.1.3-4.fc40.x86_64/usr/lib/python3.12/site-packages’: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.VbdRja (%install)
* Install a redirection index.html page to point users to the
upstream HTML documentation.
* Remove myst parser patch for RHEL.
* Remove -DLLVM_INCLUDE_DOCS
* Add lldb man-pages
I always wanted to use `mock` instead of `rpmbuild` for building release
and snapshot builds. I disliked `mock` for a very particular reason.
When a build failed and I wanted to go in and change the last running
script and re-run it, I thought this wasn't possible. Little did I know.
Here are the make targets and what they do now:
```
Available targets
-----------------
get-sources-snapshot - Downloads all sources we need
for a snapshot build.
get-sources-release - Downloads all sources we need
for a release build.
srpm-release - Builds an SRPM that can be used
for a release build.
srpm-snapshot - Builds an SRPM that can be used
for a snapshot build.
scrub-chroot - Completely remove the fedora
chroot and cache.
mockbuild-release - Start a mock build of the
release SRPM.
mockbuild-snapshot - Start a mock build of the
snapshot SRPM.
edit-last-failing-script - Opens the last failing or
running script from mock in your editor
of choice for you to edit it and
later re-run it in mock with:
"make
mockbuild-rerun-last-script-...".
mockbuild-rerun-last-script - Re-runs the last failing or
running script of your release/mock mockbuild.
help - Display this help text.
get-llvm-version-release - Determines the LLVM version
given in the llvm.spec file.
get-llvm-version-snapshot - Determines the LLVM version
given in the version.spec.inc file.
get-spec-file-release - Parses the spec file for the
Release: tag
get-srpm-release - Determines the name of the SRPM
used for release builds
Can be overriden by giving "make
... SRPM_PATH=foo.src.rpm".
get-srpm-snapshot - Determines the name of the SRPM
used for snapshot builds
Can be overriden by giving "make
... SRPM_PATH=foo.src.rpm".
```
When you want to build a release build for fedora you can do so by
running `make mockbuild-release` it will download the sources for you
and create an SRPM that it will pass to `mock` for the final build.
To build for `centos` you can use `make mockbuild-release
MOCK_CHROOT=centos-stream-9-x86_64`.
This change brings back some patches we had applied in LLVM 18.
And since the `bundle_compat_lib` switch in RHEL still builds LLVM 18,
I've added them here. This was easily possible due to #323.
This effectively allows us to build LLVM 19 in RHEL9 (see also RHEL-57461).
I've also added the `--gcc-install-dir` to the config file which is used
once clang is installed. This is to tell clang in RHEL which standard
library to link against.
We decided to no longer patch clang to default to DWARF4. Instead we tune
the default by adding `-gdwarf-4` to the config file.
RHEL-wise we've bumped the gts version from 13 to 14 (see RHEL-38228).
While we *are* building the gold plugin, I noticed that we're
no longer running the tests for it on f41 and rawhide. Add a
BuildRequires on binutils-gold to restore the tests.
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.
