Adds a simple macro which limits the CPU count which is used in the
various build-related macro. Using this macro at the beginning of the
specfile to limit the CPU count directly, or to set the CPU count based
on the amount of memory in the system and a "job size".
The default action if no options are provided is to limit builds to a
single CPU.
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
