Realizing that we have dynamic string buffer available in the macro
engine... so we don't need a dumb worst case malloc and all the other
crap in the old tag format era implementation.
as those may be Guile object files. Those are ELF files but cannot be
stripped. This may also exclude other files (like Golang sources) but
that should not be an issue.
Resolves: #1765
Those where not converted to integers for to lookup though not converted
to the actual file name.
Thanks to Vít Ondruch for pointing this out, suggesting the fix and
insisting on a test case!
Resolves: #1766
The Apple Silicon toolchain removes the *64 stat symbols (deprecated
since 10.6) in favour of their unprefixed form.
This change might not work properly before 10.6, but 10.5 has been out
of support for over a decade, so that hopefully shouldn't be relevant.
Fixes#1752.
There are legitimate reasons (such as rhbz#1940895 or the included test)
for wanting the former behavior where all file states were considered in
file queries prior to commit 9ad57bda4a,
so celebrate the tenth anniversary of that commit by adding a CLI switch
(a new package selector --path), as contemplated back then.
Update the man page for --file to reflect it's current behavior and make
--path that more obvious.
Resolves: rhbz#1940895
All current automatic macros are named in a way that do not pass the
name check in validName(), but that's kinda implicit. Specifically
test for ME_AUTO along with ME_BUILTIN.
No functional change due to the implicit protection from the naming.
Traditionally rpm has required user defined macro names to be at least
three characters long, but outlaws all sorts of useful names like %cc
for no particularly good reason - on unix a *lot* of commands are two
characters, and then there are programming languages named R and whatnot.
For macros starting with underscore, require one additional character
though so `r` is okay and so is `_r` but plain `_` is not.
The name validation and error reporting is buggy in multiple ways but not
in the mood to chase all those now, this is just the bare minimum change.
We now only invalidate the cache if the cached entry gets written
or deleted. This is needed for the code in rpmdbNextIterator()
which first reads the next header and then writes the modified
old header to the database. Therefore we must not free the cached
entry if a modified header with a different id is written.
Bump the Lua minimum version to 5.3.
The 986be669fb commit introduced a use of
lua_rotate(), which is not available in Lua 5.2, unintentionally causing a dependency on 5.3. Rather than work around it, just bump the requirement to 5.3, it's almost seven years old by now...
Otherwise SecureBoot signatures may be stripped too.
We used to exclude shared libraries from this strip as they were
supposed to be covered by another brp script (brp-strip-shared), however
it turned out the latter was never really used, so we removed the
exclusion in commit 0ab151ab13.
As it turns out, that was a little too ambitious, since we may now
inadvertently strip SecureBoot signatures from kernel modules too,
provided that they're made during the build, prior to the invocation of
brp-strip.
Note that this regression currently does *not* affect the following two
cases on Fedora/RHEL systems with redhat-rpm-config installed:
- in-tree kernel modules; these are built from kernel.spec which
already contains a hack ensuring that module signing only happens
*after* any stripping (see %__modsign_install_post in kernel.spec)
- out-of-tree kernel modules built with debuginfo enabled; this is
because brp-strip is only called when %debug_package is set to
%{nil}
Any other combinations may be affected, depending on the macros and
.spec files used, so let's fix this by effectively "reverting" said
commit for .ko files only.
Fixes: rhbz#1967291
We must avoid the "database is locked" errors at every cost because
otherwise the rpmdb gets corrupted and system ends up in inconsistent
state.
Resolves: rhbz#1946046
This covers the following usage:
expr = rex.newPOSIX(<regex>)
expr:match(<string>) # A leak occurred here
expr:gmatch(<string>, <func>) # A leak occurred here
Found by Coverity.
We permit two equivalent forms of specifying a list of languages per
file:
%lang(xx,yy,zz) /path/to/file
%lang(xx) %lang(yy) %lang(zz) /path/to/file
The leak was when parsing the second form.
Found by Coverity.
Turns out this leak is already fixed in glibc's current version of fts.c
(where our copy originates from), so let's just backport that.
Original commit in glibc:
https://sourceware.org/git/?p=glibc.git;\
a=commit;h=db67c2c98b89a5723af44df54f38b779de8d4a65
Found by Coverity.
This function is not used anywhere within our codebase (and neither is
it part of the public API) so it's basically a no-op... Still, rather
than yanking it completely, let's just silence the Coverity error here.
Found by Coverity.
Even though the actual implementation of rpmGlob() does not allocate the
passed arg list (av) if the return code (rc) is non-zero or arg count
(ac) is 0, it's the responsibility of the caller (rpmInstall() here) to
free that memory, so make sure we do that irrespectively of the above
conditions.
Found by Coverity.
These curly brackets are already treated as literals by the shell, so
let's make that explicit for clarity, and silence a ShellCheck warning
at the same time.
More info: https://github.com/koalaman/shellcheck/wiki/SC1083
Found by ShellCheck.
just create them. Otherwise their date messes up the man page
genenration and triggers a rebuild when on wanted (e.g. when building
form the tar ball)
Resolves: #1729
An RPATH or RUNPATH pointing to directories owned by a package in /usr/libexec/*
is a valid case and should be allowed by the check-rpath script.
Related: #1719
Besides rpm version string length, the file offsets also depend on
at least libmagic version and probably something else I'm missing now,
this is just too fragile to be useful. Use a pre-built package to
avoid delaying 4.17 beta just because of such a dumb thing, figure out
something better later (pre-built is not ideal as inevitably the
pre-built will need to be re-built too and that gets difficult
sometimes)
This didn't actually cure the thing it was supposed to, and there are
more factors at play anyhow (libmagic strings and all).
This reverts commit 9db0b6fbc3.
This requires generating all man pages even those not going to be
installed as their plugin in not going to be built.
As a result building from the tarball should not need pandoc for
generating the man pages.
Panu Matilainen