The Python compileall2 module in /usr/lib/rpm/redhat/
can be executed by various different Python interpreters.
We don't want to write several different `*.pyc` files
to this location - in most cases, that's not possible,
but somebody might run this as root.
For kernel builds, /usr/lib/rpm/kmod.prov is fork+execed by rpmbuild
in "Processing files:" step about 8000 times, single-threaded,
with cumulative run time of ~2 minutes.
Speed up this script, by avoiding additional fork+execing.
Tested to work, observed speedup: almost exactly 2 times faster.
While verifying correctness, noticed that old script was buggy -
it was generating a bogus "Provides:" item - kmod(modules.builtin.modinfo),
because the logic in script was filtering for */*.ko files and
for */modules.builtin* files, and wasn't prepared for
the existence of */modules.builtin.modinfo file.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
This config is to let libtool recognize that our 64bit variant of
%_libdir is actually on the standard/default library path, so libtool
doesn't think it has to be hard-wired as RPATH. This is proper solution
for libtool RPATH issues described in:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_removing_rpath
The libtool script/macros (new enough, v2.4.6+) honor this variable when
it isn't possible to detect the system-wide default library path. It is
e.g. able to parse /etc/ld.so.* configuration, but there's no info about
/usr/lib64 on Fedora.
So to not force everybody to do:
%configure LT_SYS_LIBRARY_PATH=...
... rather set this system-wide. This is low-risk change since
older libtool scripts don't use this variable, and really no other
tools should.
– handle CR in addition to LF
– be smarter in presence of lists
– fix off-by-one mistake when a LF in the processed text falls exactly on the 81st column
trim() {
printf '%s' "$*"
}
...
read shebang_line < "$f" || :
orig_shebang=$(trim $(echo "$shebang_line" | grep -Po "#!\K.*" || echo))
The "trimming", i.e. replacement of multiple spaces and removal of leading
and trailing spaces, is achieved because "trim $(cmd)" construct has an
unquoted $(), which is subject to word splitting.
This works, yes. BUT.
It is also subject to glob expansion - any ?s and *s will be attempted
to be expanded as well - definitely NOT what we want!
This change replaces this trick with code which avoids the expansion issue,
and which does not spawn any subprocesses for string manipulations -
this is ~3 times faster (fork+execs are expensive).
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Resolves: rhbz#1595265
The problem this change is intended to solve is with how `real_libdir`
is calculated. Let's assume we want to recursively byte-compile all
`*.py` files in
`/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8`.
Then, `real_libdir` is this path without `$RPM_BUILD_ROOT` with
the filename at the end which displays in the error message like this:
```
Bytecompiling .py files below /builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8 using /usr/bin/python3.8
*** Error compiling '/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8/site-packages/greplin/bar.py'...
File "/usr/lib/python3.8/bar.py", line 1
import sin from math
^
SyntaxError: invalid syntax
```
`/usr/lib/python3.8/bar.py` is obviously wrong.
One of the new features of the `compileall2` module (which will
be available in stdlib in Python 3.9) is that the path byte-compiled to
`*.pyc` files is calculated for each file. This means that by using
`-s` and `-p` we can strip `$RPM_BUILD_ROOT` and prepend `/` for each
file individually which will fix the problem.
```
Bytecompiling .py files below /builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8 using /usr/bin/python3.8
*** Error compiling '/builddir/build/BUILDROOT/python-scales-1.0.9-250.fc32.x86_64/usr/lib/python3.8/site-packages/greplin/bar.py'...
File "/usr/lib/python3.8/site-packages/greplin/bar.py", line 1
import sin from math
^
SyntaxError: invalid syntax
```
This change has an effect only for Python >= 3.4.
Instead of:
%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data='%{SOURCE0}'
It is now possible to do:
%gpgverify -k2 -s1 -d0
I haven't yet assumed any defaults not to break backwards compatibility.
Match other architectures by adding missing flags:
-fasynchronous-unwind-tables -fstack-clash-protection
This is already in Fedora/RISCV for 1+ year.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
If %source_date_epoch_from_changelog is true, RPM can set the SOURCE_DATE_EPOCH
environment variable to the timestamp of the topmost changelog entry. The
SOURCE_DATE_EPOCH can be in turn used by various projects to override otherwise
dynamically generated timestamps.
E.g. this might help to have stable timestamps in generated
documentation etc.
Rpm 4.15 removes various language-specific macros. Python side is
already covered by the versioned python macros but this is not the
case with Perl, macros. Add them here temporarily to avoid breaking
the world, but these really belong to perl-macros or such.
Once upon a time these did differ (for various bad reasons) but the
version in rpm has been identical to ours for many years, lets shed
some old baggage.
– permit extraction of multiple archives in a single specfile
– %forgemeta, %forgesetup, %forgeautosetup: add a “-z <number>” switch to
select a specific set of rpm variables
(for example forgeurl<number> and version<number>)
– %forgemeta, %forgesetup: add a “-a” switch to process all sets in one go
(makes no sense in forgeautosetup, as you need so select specific patches)
– %forgemeta: deprecate the “-u” switch, use “-z” it’s better
(“-u” was awkward and mainly used by the %gometa macro. %gometa will now
call the lua code directly)
– %forgesetup: use “-v” for verbose processing, be quiet by default, drop “-q”
(align with %forgemeta, %forgeautosetup and %autosetup)
– %forgesetup, %forgeautosetup: only pass flags that make sense to
%setup/%autosetup; reorder to match what works in el7
– factor out complex or common lua code in separate lua modules, to allow:
– code reuse in other macros without cut and pasting
– direct lua routine invocation from other macros without going through a
rpm macro
– rpm syntax errors that point to a line in an actual lua file
– %forgemeta: refactor the logic to drop as much forge-specific code as
possible, use a single logic flow with tables of constants
– %forgemeta: export more computed info in rpm variables, such as the
%{_builddir} subdirectory an archive was extracted to (lifesaver when
processing multiple archives)
– %forgemeta: prepend secondary distprefixes with .S, to make clear they do
not apply to the main archive
– %forgemeta: add versionx to secondary distprefixes, if relevant
– %forgemeta: make tar.bz2 the default archive format
Caveats:
– forge services implement full-release downloads via tags. However the actual
syntax of such tags is not standardised. If the macro does not guess the
correct tag an upstream uses for a specific release, you will need to
set the tag value explicitly.
– GitHub lets upstreams move their projects to new URLs, keeping the old URL
active. It all works transparently *except* the top directory inside
generated archives always matches the new project name (even when accessed
by compatibility URLs, and even for releases that antedate the renaming).
Therefore, if macro processing of a GitHub archive suddenly fails, start by
checking if upstream didn’t rename itself.
Multicall usage example (with “-a”)
– to process a specific bloc in one of the macros use “-z <suffix>”
– suffix 0 and no suffix are synonyms
– therefore, calling the macros without “-a” or “-z” just works for the
general use case when you have a single archive to process
– caveat: forge services implement full-release
%<--
%global forgeurl0 https://gitlab.com/osslugaru/lugaru
Version: 1.2
%global forgeurl1 https://gitlab.com/osslugaru/lugaru
%global tag1 1.1
%global forgeurl2 https://gitlab.com/osslugaru/lugaru
%global commit2 68488b0a11df90dca703c67e5592b93c6a269957
%global forgeurl3 https://gitlab.com/osslugaru/lugaru
%global branch3 v1.1
%global forgeurl4 https://github.com/google/trillian
%global version4 1.0.8
%global forgeurl5 https://github.com/kubernetes/apiextensions-apiserver
%global version5 1.9.6
%global tag5 kubernetes-%{version5}
%global forgeurl6 https://github.com/jdbranham/grafana-diagram
%global version6 1.3
%global commit6 440689793ab6da82019c5ee43b49438dfef976d5
%global forgeurl7 https://github.com/rethinkdb/rethinkdb-go
%global version7 1.4.2
%global branch7 v1
%global forgeurl8 https://code.googlesource.com/gocloud
%global version8 0.20.0
%global forgeurl9 https://code.googlesource.com/gocloud
%global tag9 v0.27.0
%global forgeurl10 https://code.googlesource.com/google-api-go-client
%global commit10 24928b980e6919be4c72647aacd53ebcbb8c4bab
%global version10 0
%global forgeurl11 https://code.googlesource.com/google-api-go-client
%global branch11 dartman
%global forgeurl12 https://bitbucket.org/nielsenb/pdfocr
%global version12 0.3.0
%global commit12 4f5750d202d33267094621630836f1215a5efa66
%global forgeurl13 https://bitbucket.org/nielsenb/pdfocr
%global version13 0.1.4
%global tag13 v0.1.4
%global commit13 c0359843a3420769940e12019ebd68891a053bd8
%global forgeurl14 https://bitbucket.org/creachadair/shell
%global commit14 3dcd505a7ca5845388111724cc2e094581e92cc6
%global forgeurl15 https://bitbucket.org/kirbyvisp/vdjpuzzle2/
%global branch15 js-edits
%global commit15 36a3850eb4a04c05e0f7e29e7d0c196f373eb672
%forgemeta -ia
Name: testing
Release: 1%{?dist}
Summary: A test package
URL: %{forgeurl}
License: Public domain
Source0: %{forgesource0}
Source1: %{forgesource1}
Source2: %{forgesource2}
Source3: %{forgesource3}
Source4: %{forgesource4}
Source5: %{forgesource5}
Source6: %{forgesource6}
Source7: %{forgesource7}
Source8: %{forgesource8}
Source9: %{forgesource9}
Source10: %{forgesource10}
Source11: %{forgesource11}
Source12: %{forgesource12}
Source13: %{forgesource13}
Source14: %{forgesource14}
Source15: %{forgesource15}
%description
A test package
%prep
%forgesetup -a
%build
exit 1
%install
%files
%doc
%<--
Merges: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
It says more where to look and what it is supposed to do.
Acked-by: Florian Festi <ffesti@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Sadly, ldc ppc64 support has detoriated so much that it no longer works
with any current llvm version. I'll keep an eye on things and re-enable
it once it's fixed, but right now it's just broken and upstream is
suggesting to disable the support for now.
https://github.com/ldc-developers/ldc/issues/2356
find-provides.ksyms and find-requires.ksyms contain macros for
generate external kernel module symbol dependency table.
These scripts are broken in fedora for long time.
Patch fix both and make it useable again.
-Petr
Signed-off-by: Petr Oros <poros@redhat.com>
Using the modification time of the snapshot tarball for computing dist is a bad idea, since it's different on different machines.
For example, the computed date during the `buildSRPMfromSCM` koji task is likely different from the local date when the package was prepared, and so package builds (especially EVRs and changelog entries) are not reproducible.
With this change, the snapshot date is not calculated magically, but the packager has to set "%global date YYYYMMDD" manually. I also adapted the documentation for the macro to reflect that change.
This is related to the following FPC issue: https://pagure.io/packaging-committee/issue/719
This patch adds two additional rpm macros, __brp_mangle_shebangs_exclude_file
and __brp_mangle_shebangs_exclude_from_file, to specify files from which
to read the extended regexps used for excluding shebangs and target
files.
Additionally, this adds documentation in the macros file and
--help/--usage/-?/-h to brp-mangle-shebangs, so that it's possible to
actually discover what the intended behavior is without reading the
script itself.
Signed-off-by: Peter Jones <pjones@redhat.com>
If %ldconfig is not defined, then "%ldconfig_post/%ldconfig_postun foo"
will expand to " foo" which is breaking packages.
Also now it is possible to move %end into post/postun.
Reported-by: Terje Røsten <terjeros@phys.ntnu.no>
References: https://bugzilla.redhat.com/show_bug.cgi?id=1548331
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
If people choose to use %ldconfig_post/%ldconfig_postun, let them to
deal with %end.
Reported-by: Harald Reindl <h.reindl@thelounge.net>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1547838
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Some people tend to use comments in spec files which adds them into the
scriptlet and we don't want this.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Now it starts requiring bash instead of POSIX-compatible shell, but this
is not a problem since other scripts in here do same.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Introduces __brp_mangle_shebangs_exclude_from and __brp_mangle_shebangs_exclude
* the first allows to explude specific paths from the mangling
* the second allows to exlude specific shebangs
Both are used with `grep -E`. Similar escaping rules as in [1] apply.
[1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
With https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
we try to remove ldconfig scriptlets, but it would make every package
look horrible with all those conditionals. So let's just wrap ldconfig
scriptlets into macro so it doesn't look that horrible and error-prone.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
If there are unpackaged symlinks, build will fail with unpackaged files.
People can %undefine __brp_ldconfig if they need to and they should make
sure that they call ldconfig themselves.
Right now, script doesn't guide packagers what to do, but it's not
prerequisite.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Add a separate macro for each brp we have, using standard naming
convention and conditionalize the usage in %__os_install_post.
Voilà, we have a standard way to disable (and also override) any brp
scripts from specs that need it and a common scheme for new brps
to follow.
Note that this is not supposed to change the existing behavior and
default build root policy invocations at all, any change in those
would be a thinko/typo/copy-paste error in this commit.
It doesn't belong to redhat-rpm-config which is about *srpm* buildtime..
This reverts commit ea5600c887.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Since b5ea4b290b we started to require gcc
(because annobin requires gcc). Since annobin does work only with gcc,
we don't have to install it if user doesn't have it.
Reported-by: Dominick Grift <dac.override@gmail.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Per fweimer: "Sorry, we need to revert the -Werror=implicit-*
bits. There is no chance we can get this working in any
reasonable time frame, there is simply too much breakage."
Introduce new language specific __global_fooflags for C, C++ and Fortran
This looks mildly strange and suspicious since because the global flags
get pulled in indirectly via %optflags (that doesn't change here but becomes
more obvious).
Depends on previous commit (8fe5b07871)
which was done separately to make the actual change (or lack of thereof)
stand out here.
This is not supposed to change any actual values for current usages,
so if it does it's a bug.
However there's a minor bonus involved for Fortran users who can now get
the correct FFLAGS/FCFLAGS for non-autoconf projects too by using
__global_fflags/fcflags
Preparing for language specific compiler flag macros, this is
simply:
perl -pi -e "s:__global_cflags:__global_compiler_flags:g" macros rpmrc
Since this looks like a much bigger change than it actually is, doing
it in a separate step without an associated build.
The hardened gcc specs do not handle static linkage, so building
with -static has been broken since commit
d9235d2d90. Adjust the -ld spec
file to avoid -pie when static linkage is used, as suggested
by Florian Weimer.
If java people say brp-java-repack-jars is not needed then it
probably isn't (#1235770). brp-implant-ident-static hasn't been enabled
in 13+ years, I THINK it's safe to say its not critically needed.
Leaving the actual scripts in the repo for now (amusement for
archeologists of future generations, eh?)
One possible incompatibility, hopefully non-issue: our brp-strip*
allowed setting strip and objdump to use via args and STRIP and
OBJDUMP env vars whereas the rpm ones allow it through args only
(i.e. %{__strip} and %{__objdump} as far as specfiles are concerned).
Specifically, the following are gone from here now: %_prefix,
%_sysconfdir, %_infodir, %_mandir, %_defaultdocdir, %_configure,
%makeinstall, %debug_package, %_use_internal_dependency_generator,
%_missing_doc_files_terminate_build, %_unpackaged_files_terminate_build
- Packages that refer to /usr/lib/rpm/redhat/find-requires|provides
do exist afterall, bring the scripts (but NOT macro overrides for them)
back until the packages (python3 at least) are fixed.
- Use rpmdeps to generate any "normal" dependencies even for the
kernel module stuff, drop all other unnecessary duplication
like elf, libtool and pkgconfig deps.
- Stop overriding rpm external dependency generator settings by default
- No normal package should ever end up using the old unmaintained
dependency generator scripts from here, but the kmp system depends
for now on the way this was previously set up here so letting
that old cruft live in the non-default package for now.
- These are not very relevant for Fedora, more so for RHEL and derivates
where it would be far preferrable to maintain the scripts as separately
from Fedoras redhat-rpm-config package as they are unmaintained and
only get out of sync here. Splitting these to a separate package
is the first step towards that.
- This isn't supposed to affect Fedora packages in any way.
all patches dropped as they're no longer relevant
- Add maintainer comments to spec wrt versioning and changes
- Except for Changelog documentation, the resulting binary package
is identical to previous version (9.1.0-58), ie only maintenance
practise is changed here, not contents.
This reverts commit 8174ec3d10.
remove patch that forces --disable-silent-rules to configure it breaks anything set to not ignore unknown configure options
Various projects have been adding AM_SILENT_RULES from Automake to
their Makefiles for "developer convenience"; the goal being that they
see warnings more easily.
Now really the right way to do this is to have a make wrapper (or an IDE)
that knows how to filter out warnings, but let's leave that aside for now.
But for debugging builds, we really need the full log data. Being
able to see exactly how e.g. libtool is being run helps a lot for
debugging link problems as an example.
All ARM version 7 systems support a vector hardware floating point unit and
have the ability to run using the hard floating point ABI (aapcs-vfpv3-d16).
This is the only configuration we support as a v7 target, so we force the
use of hard floating point. This prevents e.g. packages being built with
a armv5tel target on an armv7 system without explicit intent.
Signed-off-by: Jon Masters <jcm@jonmasters.org>
All ARM version 7 systems support a vector hardware floating point unit and
have the ability to run using the hard floating point ABI (aapcs-vfpv3-d16).
This is the only configuration we support as a v7 target, so we force the
use of hard floating point. This prevents e.g. packages being built with
a armv5tel target on an armv7 system without explicit intent.
Signed-off-by: Jon Masters <jcm@jonmasters.org>
- brp-strip-comment-note is not only unnecessary here but is also
now messing up things by resetting EI_OSABI to zero (#568921)
- patch from Roland McGrath
- regression originating from commit 9ed9b4e345
which was supposed to fix something for on ARM but broke pretty much
all else
- this should've been in 9.1.0 but somehow gone missing, ugh...
- fix originally from Bill Nottingham
- with %_python_bytecompile_errors_terminate_build set to non-zero,
byte-compilation errors will abort the build, this helps catch out
silly "improt foo" syntax errors early on
- not all .py files are valid python (they can be templates, inteded for
jython consumption etc), and what's valid can depend on the python
version (notably 2.x vs 3.x) so allow overriding from spec
#458648)
- require rpm for parent dir, version >= 4.6.0 for sane keyserver behavior
- buildrequire libtool to grab copies of config.guess and config.sub
- add URL to the git repo and upstream changelog as documentation
- rpm < 4.6 used to try and fetch and import any missing keys from
keyserver automatically on rpmdb iteration if hkp_keyserver was set, which
caused hideous slowdowns and huge load on pgp keyservers AND was a
security hazard as rpm thinks imported == trusted key. This is safe
enable now as rpm will only ever import keys when explicitly told to do
so with --import
- this makes pgp import directly from PGP servers work, ie
'rpm --import 0x<keyid>'
- these used to have RH-specific hacks in them and %configure used to
copy updated versions to builddir on invocation but neither is done
now, these are just copies of upstream (libtool / automake) versions
so there's no point dragging them along
- some packages might expect to find them in /usr/lib/rpm/redhat/ so
perhaps spec should copy them at build-time from automake/libtool
to ensure a recent version
- rpm's dep extractors have gotten numerous improvements over the years,
while the ones here haven't seen any updates since 2002
- point the find-* scripts to rpm's scripts, remove the redundant and
outdated perl.* scripts
- autotools dependency tracking isn't generally useful in rpm builds;
disabling it results in cleaner build logs and possibly slight build speedups
- patch from Ville Skyttä
- --target is only ever useful for handful of compiler toolchain packages
and cross-compiler packages are better off setting it themselves if
necessary, rpm messing here only gets in the way
- patch originally from Stepan Kasal
- syncs up with rpm upstream setup
- FFLAGS has a Fedora-specific override forcing us to carry this %configure
copy, need to fix rpm to permit more fine-grained overrides...
- as per https://fedoraproject.org/wiki/Features/XZRpmPayloads
- lowish compression preset level to keep deltarpm rebuild time tolerable
- source rpms dont really benefit from XZ compression as the contents are
typically tarballs which are already compressed
- patch from Bill Nottingham
- remove any existing buildroot contents and safely create a new one
- patch originally from OpenSUSE / Michael Schroeder, adopted to Fedora
by Tom "spot" Callaway
- as per http://fedoraproject.org/wiki/Features/ArchitectureSupport
- set 32 bit intel build arch to i586 on compatible hardware
- set 32 bit sparc build arch to sparcv9 on compatible hardware
- add missing armv7l arch
- set the default build arch to match fedora arm build target
- arm fixes (Lennert Buytenhek, #243523)
- allow jar repacking to be disabled (#219731)
- fix running dist.sh --fc (#223651)
- hardlink identical .pyc and .pyo files to save space (Ville Skyttä)
- fix TMPDIR usage (Matthew Miller, #235614)
On Fri, 29 Jul 2005, Ulrich Drepper wrote:
> Please find attached the hopefully final changes for the compile flags.
> It's a patch against redhat-rpm-config-8.0.36-1.src.rpm. The changes are:
>
> ~ enable stack protector with minimal size 4 (default is 8, too high
> IMO). Vlad ran some tests on SPEC. SPEC is highly CPU intensive,
> unlike 90%+ of the distribution. Even in those tests the performance
> decrease was below 1%, probably even in the noise. Especially the
> decrease of the minimum size to 4 made no measurable impact.
>
> ~ remove the -fsigned-char flag for ppc. glibc has not been compiled
> with the flag anyway, so if anything changes, we eliminate some bugs.
> The only theoretical issue would be if a library we ship uses CHAR_MAX
> in an interface. I personally haven't seen this for good reasons.
> The only interface I know is localeconv(3) in glibc and this interface
> is now corrected.
>
> ~ minor fix for SPARC
- update config.{guess,sub} to 2003-06-17
- define VENDOR to be redhat only when /etc/redhat-release present
[suggested by jbj]
- put VENDOR in vendor field in our config.guess file for
ia64, ppc, ppc64, s390, s390x, x86_64 and elf32-i386 Linux
- drop the --host, --build, --target and --program-prefix configure options
from %%configure, since this causes far too many problems
file, because that will start overriding things like %{_lib} -- probably
more could have been snipped, but the remaining bits are at least
moderately reasonable to make sure are defined according to "our policy"
rpm.expand("%{echo: (snapshot date is either manually supplied or computed once %%{_sourcedir}/%%{archivename"..suffix.."}.%%{archiveext"..suffix.."} is available)}")