If busybox diff is used then script doesn't generate output when
rpmbuild is checking for installed (but unpackaged) file(s). This is
because busybox diff use unified format: '-' instead '< '.
For kernel build, "${LISTFILE}.dirs.sed" is debugfiles.list.dirs.sed
and it contains 1782 lines of sed script.
It is applied to two files, both are about 4450 lines long.
This is slow (~30 seconds) because of ~16 million regex matches
performed by sed.
But we don't need or want regex match here
(and it's buggy, since dots in pattern match will be treated
as "any character", which is wrong here. For example,
/usr/lib/debug/lib/modules/5@4@0-0@rc7@0@fc31@test@x86_64/vdso/
would match
/usr/lib/debug/lib/modules/5.4.0-0.rc7.0.fc31.test.x86_64/vdso/
pattern, but it should not).
This change performs matching using shell string comparison ops.
For kernel build, this change results in run time of about one second.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Message translation in scripts via $-prefix is bash-specific, but
check-rpaths is a /bin/sh script, drop the bashism. There are no
translations anyway so this is a no-op for all practial purposes.
Originally reported and fixed in Debian (DebBug:772404)
Fixes https://github.com/rpm-software-management/rpm/issues/995
For this input: pyparsing>=2.0.1,!=2.0.4,!=2.1.2,!=2.1.6
Instead of (invalid):
(python3.8dist(pyparsing) >= 2.0.1 with
python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with
python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with
python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)
Produces (valid):
(python3.8dist(pyparsing) >= 2.0.1 with
(python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0) with
(python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0) with
(python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0))
For this input: babel>=1.3,!=2.0
Instead of (invalid):
(python3.8dist(babel) >= 1.3 with
python3.8dist(babel) < 2 or python3.8dist(babel) >= 2.0)
Produces (valid):
(python3.8dist(babel) >= 1.3 with
(python3.8dist(babel) < 2 or python3.8dist(babel) >= 2.0))
For this input: pbr!=2.1.0,>=2.0.0
Instead of (invalid):
(python3.8dist(pbr) >= 2 with
python3.8dist(pbr) < 2.1 or python3.8dist(pbr) >= 2.1.0)
Produces (valid):
(python3.8dist(pbr) >= 2 with
(python3.8dist(pbr) < 2.1 or python3.8dist(pbr) >= 2.1.0))
as it is not POSIX compliant and not supported on BSD and others
Dropping the use of grep here and using -regex of find instead to get rid of
the need for looking at lines terminated by newline.
Using only basic regular expressions for portability.
Resolves: #948
There's plenty of documentation pointing to /usr/lib/rpm/rpmdb_dump
and rpmdb_load, which always were BDB specific utilities. Add a simple
wrapper scripts by the same names that perform --exportdb/--importdb
which is the database agostic way to achieve roughly the same as the
BDB tools by the same name used to do.
There's code setting variable id in scripts/find-debuginfo.sh, but there's no
subsequent use. The only use of $id in the script is in do_file, where it is
a local variable.
The variable setting was introduced in commit 6b3b435fa "Add dwz debuginfo
compression support" in combination with a subsequent make_id_link using the
variable, but the make_id_link was removed in commit bbfe1f86b
"Add build-id links to rpm for all ELF files".
Remove the unused variable.
Prefer '[] && []' to '[ -a ]' and '[] || []' to '[ -o ]' in tests.
-a and -o to mean AND and OR in a [ .. ] test expression is not well
defined, and can cause incorrect results when arguments start with
dashes or contain !. Moreover binary -a and -o are inherently
ambiguous. test(1) man page recommends to use
'test EXPR1 && test EXPR2' or 'test EXPR1 || test EXPR2' instead.
It corrects warnings [SC2166] spotted by covscan.
Spotted by covscan:
warning: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined. [SC2166]
Originally introduced in commit 9aae21d.
Thanks to Florian Festi for spotting this and proposing the solution.
With the introduction of the annobin gcc plugin to the build process,
built binary files have become larger. Sometimes significantly so.
This is a patch that adds a new step to the post-link process performed
by rpmbuild, to run the objcopy program with the --merge-notes option
specified. This will reduce the size of the annobin notes in binary
files, thus alleviating the size growth.
The change made in fc2c986 can break for large values of %_smp_build_ncpus as
this many processes are able to overflow the following pipe.
Thanks to Denys Vlasenko for testing this.
This change solves this problem by running a whole processing pileline for each
parallel (file) process. This has also the benefit of running at least some
stip commands in parallel.
The -n param fro xargs was increased to 32 to further reduce the over head of
spawing the helpers as they are now needed for each run of the file command.
to speed the script up for large number of files to be looked at.
Use xargs -P instead of find -exec.
Add xargs to the test environment
Resolves rhbz1691822
The find-debuginfo.sh flag -g had exactly this meaning. But from
version rpm-4.13.0-alpha flag -g changes its behavior. It affects
both libraries and executables.
For some packages the original behavior was preferred. That is why
the new find-debuginfo.sh flag --g-libs is created.
Options -g and --g-libs are mutually exclusive.
Since file 5.33, PIEs are identified by a new MIME type, meaning that,
currently, for such executables, the .gnu_debugdata section is not
added, even if -m is passed.
Signed-off-by: Ernestas Kulik <ekulik@redhat.com>
Having these kind of macros has increasingly forced us to ponder questions
like "what is the system default python", which have absolutely nothing
to do with rpm. And to that issue the only possible solution is eliminating
such content from rpm.
And yes this will break existing packages and force distros to deal
with the fallout, but we believe its for the best:
these macros are also best maintained by people closer to the languages
in question, as has been done with all the newer languages predating
perl and python. rpm-extras exists as the place for maintaining and
collaborating on such material.
brp-compress used to be all hardcoded around /usr for no good reason.
Support passing prefix as an argument and only look for things to
compress there. First attempt in 5e65f92b53
had an embarrassing typo/thinko/case of missing brain in the assign syntax.
Based on feedback and work of Owen Taylor and Yanko Kaneti in PR #538
brp-compress used to be all hardcoded around /usr for no good reason.
Support passing prefix as an argument and only look for things to
compress there.
Based on feedback and work of Owen Taylor and Yanko Kaneti in PR #538
By standard, 'du' defaults to 512 byte units, but this differs between
implementations: GNU du defaults to 1024 unless POSIXLY_CORRECT is set
and also allows overriding via number of environment variables. It also
supports various other ways of controlling the block size, but the
only standard means to control the size is -k, and we really don't
want to break portability for the sake of FYI statistics.
Inspired by Marxim Liska's patch at in #554.
This is breaking suid bit handling in packaging unless an unreleased
bleeding edge version of elfutils is used. In other words it's not
an acceptable requirement and wont be for a long time. This needs
to be fixed in some other way.
This reverts commit 1c3bf3d649.
to make build results more reproducible
in spite of indeterministic filesystem readdir order.
For openSUSE, this helped to make squid, openssh, postfix and shadow
packages build reproducibly.
See https://reproducible-builds.org/ for why this is good.
This typo has always been there since the initial implementation in
Fedora-specific patches in 2012 and inherited upstream. Which suggests
something hasn't been working right all this time, or then this will
break something all of a sudden...
The purelib and platlib were both defined to /usr/lib64/python on
64bits systems. This is because:
>>> get_python_lib(standard_lib=1, plat_specific=0)
'/usr/lib64/python3.7'
>>> get_python_lib(standard_lib=1, plat_specific=1)
'/usr/lib64/python3.7'
>>> get_python_lib(standard_lib=0, plat_specific=0)
'/usr/lib/python3.7/site-packages'
>>> get_python_lib(standard_lib=0, plat_specific=1)
'/usr/lib64/python3.7/site-packages'
So now we use standard_lib=0 to get the site-packages base path
from /usr/lib and not /usr/lib64.
debugedit and dwz do not support DWARF compressed ELF sections, let's
just decompress those before extracting debuginfo.
Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
When matching the module names demand a string of allowed characters
instead accepting everything and relying on terminating characters to
end the name.
Thanks to Jitka Plesnikova for the patch.
A new version of file (5.33) changed the output for PIE executables.
Which are now represented as application/x-pie-executable; charset=binary.
The following change simply recognizes that binary format as one for
which -g applies. This fixes accidental stripping of the .symtab in
glibc (which use -g to keep that symbol table).
https://bugzilla.redhat.com/show_bug.cgi?id=1581224
Signed-off-by: Mark Wielaard <mark@klomp.org>
One can now unset %_python_bytecompile_extra (or set it to 0) to
opt out from Python bytecompilation outside of
/usr/lib(64)?/pythonX.Y.
One can also set %_python_bytecompile_extra to 1 to explicitly
opt in, even tough this is currently still the default.
Python bytecompilation of files outside of Python's own
directories (/usr/lib(64)?/pythonX.Y) with /usr/bin/python is
error prone. For context, see this Fedora change [1], it describes
all the problems and provides a longer explanation about why we
are doing this.
[1] https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation
Also adds _python_bytecompile_errors_terminate_build macro which is passed to
the brp-python-bytecompile script.
Fixes#434
This added check figures out whether invoking $default_python is necessary
and exits early if no files would be bytecompiled by the two blocks below.
This prevent's invoking $default_python (i.e. %{__python} (i.e. most likely
/usr/bin/python)) when not needed. Currently (before this change) it has
been invoked twice for each build (iff the executable was present in the
buildroot), even tough in most cases it did nothing. While this might have been
harmless, it prevents us to deprecate or even forbid /usr/bin/python invocation
during RPM build as proposed in Fedora in [1].
While this change is driven by Fedora's needs, I believe it can be useful
for others as well. It doesn't render the script utterly more complex,
while it prevents it from doing 2 superfluous (possibly slow) operations.
[1]: https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build
elros34