If there are no .o/.a files to be distributed, this prevents
check_convert_bitcode from being called without a file argument,
in which case the first flag is going to be treated like the file
name, resulting in something like:
realpath: invalid option -- 'O'
Try 'realpath --help' for more information.
Usage: file [-bcCdEhikLlNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]
[--mime-type] [-e <testname>] [-F <separator>] [-f <namefile>]
[-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]
<file> ...
file -C [-m <magicfiles>]
file [--help]
From https://bugzilla.redhat.com/2083296:
> The issue is that some packages break up the flags at spaces,
> in order to look for specific flags or to add flags of their own.
> The z3 package, for example, has some python code that does this:
>
> def exec_cmd(cmd):
> if isinstance(cmd, str):
> cmd = cmd.split(' ')
> ...
>
> The result is one of the commands in the list consists of a single tab character.
> When that is passed to the compiler, the compiler does not like it at all.
Packages which do not have %%build section but do also
compile and link test programs in %%check would fail because
no package note would have been generated.
This is already the default for ld.bfd, so this is effectively a no-op
for most packages. However, lld defaults different build-id algorithm
that the RPM build process does not support, so it needs this flag.
This flag can be overriden by setting the %_build_id_flags macro,
which packages could do if they wanted to use a more secure build-id
algorithm.
Also move this file to kernel-srpm-macros. Note that we need to require
a new kernel-srpm-macros release now, since that's where kmod.attr is
going to end up.
We did this in RHEL-8 [1] so let's not re-introduce the packages in RHEL-9.
Previously, we did that by keeping a downstream-only patch - let's just
have a conditional here, to make the maintenance simpler.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1588575
The brp-llvm-compile-lto-elf script uses PCRE in grep to match
for the -flto flag in bitcode object dumps, using negative
lookahead to exclude the case where -fno-lto is specified after.
When lines in the bitcode dump exceed the length that PCRE can
match against, grep will error out causing brp-llvm-compile-lto-elf
to fail.
This script implements an equivalent regex match in python to avoid
the limit in PCRE grep.
Resolves: rhbz#2017193
The annobin clang plugin is not actually used anywhere, so we don't
need to have a dependency on it.
This was also creating a circular dependency that was blocking the
latest clang update.
RPM requires macros to be at least 3 characters, so we need to
rename the cc macro anyway and using the build_ prefix is consistent
with other macros like build_cflags.
number of CPUs will never be set to less than 1
this now outputs build flag overrides to be used with %make_build etc.
add documentation
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
A number of cases have cropped up where things like documentation
builds fail with out of tree builds because tools like Doxygen like
encoding the build path into the documentation metadata.
This causes failures in Koji and other places where noarch documentation
subpackages from archful packages fail because they fail the comparison
check due to this.
This allows us to maintain our own BuildRoot Policy scripts in an easier way.
This change needs to be coordinated with the addition of the files to python-srpm-macros.
redhat-rpm-config requires python-srpm-macros, so no significant change is expected for the packagers.
This also moves the Python BRPs to the end of the list which should be fine.
The script was dropped in rpm 4.17.0 beta1, so we can't very well
try to use it on builds. For now I'm intentionally dropping just the
macro definition: in case the Python community wants to bring it
back, all they need to do is revive the script and add the macro
definition for it.
On armv7hl, enabling annobin can in some cases lead to corrupt unwind
information in generated object files:
https://bugzilla.redhat.com/show_bug.cgi?id=1951492
The root-cause of this is still unclear and until this is sorted out,
it is best to disable annobin on the architecture.
If the file we are trying to mangle a shebang in has
0 lines (as reported by `wc`) `read` command fails
to read the first line and the script fails silently.
Text files without newlines should not be executable as there
is no way for them to contain a shebang.
Avoid using the full path and instead rely on PATH being correctly set
up to find the executable.
This fixes byte compilation for python2.7 when doing flatpak module
builds where python2.7 can be in either /usr/bin or /app/bin, depending
on how it's compiled.
Some packages require being able to redefine the compiler variables
set to add additional base arguments that must be used everywhere.
This change makes it possible for that to work correctly.
The kernel doesn't do a complete build for all arches. And example is i686 in Fedora, where only kernel-headers is built.
kernel-srpm-macros provides %kernel_arches so that the various packages have a consistent way to check for this.
A new script brp-fix-pyc-reproducibility creates an opt-in way of how to fix
problems with the reproducibility of byte-compiled Python files. The script
uses marshalparser [0] which currently doesn't provide solutions for all issues
but can fix at least problems with reference flags. For more info see
this Bugzilla [1].
If you want to use this new feature, you need to define
`%py_reproducible_pyc_path` to specify a path you want to fix `.pyc`
files in (recursively) and build-require /usr/bin/marshalparser.
if you forget to build-require the parser. The error message is:
```
+ /usr/lib/rpm/redhat/brp-python-bytecompile '' 1 0
Bytecompiling .py files below /builddir/build/BUILDROOT/tldr-0.5-2.fc33.x86_64/usr/lib/python3.9 using /usr/bin/python3.9
+ /usr/lib/rpm/redhat/brp-fix-pyc-reproducibility /builddir/build/BUILDROOT/tldr-0.5-2.fc33.x86_64
ERROR: If %py_reproducible_pyc_path is defined, you have to also BuildRequire: /usr/bin/marshalparser !
error: Bad exit status from /var/tmp/rpm-tmp.UUJr4v (%install)
```
A build fails if the parser is not able to parse any of the `.pyc` files.
And finally, if a build is properly configured it produces fixed `.pyc` files.
Currently, `.pyc` files in the tldr package contain a lot of unused reference flags:
```
$ dnf install -y tldr
$ marshalparser --unused /usr/lib/python3.9/site-packages/__pycache__/tldr.cpython-39.pyc
… long output …
190 - Flag_ref(byte=9610, type='TYPE_SHORT_ASCII_INTERNED', content=b'init', usages=0)
191 - Flag_ref(byte=9633, type='TYPE_SHORT_ASCII_INTERNED', content=b'source', usages=0)
192 - Flag_ref(byte=9651, type='TYPE_SHORT_ASCII_INTERNED', content=b'argv', usages=0)
193 - Flag_ref(byte=9657, type='TYPE_SHORT_ASCII_INTERNED', content=b'print_help', usages=0)
194 - Flag_ref(byte=9669, type='TYPE_SHORT_ASCII_INTERNED', content=b'stderr', usages=0)
195 - Flag_ref(byte=9682, type='TYPE_SHORT_ASCII_INTERNED', content=b'parse_args', usages=0)
196 - Flag_ref(byte=9737, type='TYPE_SHORT_ASCII_INTERNED', content=b'encode', usages=0)
197 - Flag_ref(byte=9782, type='TYPE_SHORT_ASCII_INTERNED', content=b'parser', usages=0)
198 - Flag_ref(byte=9790, type='TYPE_SHORT_ASCII_INTERNED', content=b'options', usages=0)
199 - Flag_ref(byte=9799, type='TYPE_SHORT_ASCII_INTERNED', content=b'rest', usages=0)
200 - Flag_ref(byte=9821, type='TYPE_SHORT_ASCII_INTERNED', content=b'result', usages=0)
202 - Flag_ref(byte=10022, type='TYPE_SHORT_ASCII_INTERNED', content=b'__main__', usages=0)
203 - Flag_ref(byte=10102, type='TYPE_SHORT_ASCII_INTERNED', content=b'argparse', usages=0)
204 - Flag_ref(byte=10433, type='TYPE_SHORT_ASCII_INTERNED', content=b'__name__', usages=0)
205 - Flag_ref(byte=10463, type='TYPE_SHORT_ASCII_INTERNED', content=b'<module>', usages=0)
```
This new feature fixes them:
```
$ marshalparser --unused /usr/lib/python3.9/site-packages/__pycache__/tldr.cpython-39.pyc
<empty output>
```
[0] https://github.com/fedora-python/marshalparser
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1686078
This cuts the kernel provide generation time from ~33s to 2.5s on my laptop.
Tighten the path matching rule a bit while at it - it doesn't matter that
much with parametric generator but there's no point looking at entries
we don't generate dependencies on.
