Despite all the Lua magic we already do, it's annoyingly often the case
that shelling out is easier (or at least shorter) than doing the same in
Lua (substrings, length etc)
Add shorthand macros %gsub, %len, %lower, %rep, %reverse, %sub and
%upper which simply wrap the corresponding Lua string.* functions for
convenience.
brp-strip script runs strip command on deliverables paralley and if
deliverables are hard linked inside buildroot, it will create
contention.
One good example for such package is git.
https://github.com/vmware/photon/blob/master/SPECS/git/git.spec
```
Sample output:
$ rpm -ql git | grep libexec | xargs ls -li
668153 -rwxr-xr-x 137 root root 3401056 Aug 2 08:30 /usr/libexec/git-core/git
668153 -rwxr-xr-x 137 root root 3401056 Aug 2 08:30 /usr/libexec/git-core/git-add
787238 -rwxr-xr-x 1 root root 47770 Aug 2 08:30 /usr/libexec/git-core/git-add--interactive
668153 -rwxr-xr-x 137 root root 3401056 Aug 2 08:30 /usr/libexec/git-core/git-am
```
To overcome this, we run strip twice once for all files with no
hardlinks, this is a parallel job, meaning multiple binaries will be
stripped in parallel.
And once for files with hardlinks, in this case we disable parallel
processing and strip binaries in sequential order.
RH bug link:
https://bugzilla.redhat.com/show_bug.cgi?id=1959049
Co-authored-by: Dweep Advani <dadvani@vmware.com>
Signed-off-by: Shreenidhi Shedi <sshedi@vmware.com>
Packages need to be able to differentiate between install and upgrade
scenarios, seems commit ab069ec876 with
half the lights out...
As %posttrans happens after all the excitement, with the erasure elements
already executed, so the installed package count cannot be used to
differentiate between install and upgrade. So we need to find it out the
hard way: see if there's an erasure element that depends on this
package.
For the very unlikely case when openat() succeeded but fstatat()
doesn't, the directory descriptor may be leaved opened. Rearrange
the code a bit to ensure it'll always get closed when appropriate.
Suggested-by: Pavel Kopylov <pkopylov@cloudlinux.com>
Suggested-by: Dmitry Antipov <dantipov@cloudlinux.com>
- switch to read only and non blocking mode for pipe
- add 1 minute loop to wait for pipe to reappear
Sometimes during the system update/upgrade fapolicyd
get restarted e.g. when systemd gets updated.
That can lead to the situation where fapolicyd pipe
has been removed and created again.
In such cases rpm-plugin-fapolicyd gets stuck on
write() to the pipe which does not exist anymore.
After switching to non blocking file descriptor
we can try to reopen the pipe if there is an error
from write(). Assuming that a new pipe should appear
when fapolicyd daemon starts again.
If not then after 1 minute of waiting we expect
fapolicyd daemon to be not active and we let the
transaction continue.
Signed-off-by: Radovan Sroka <rsroka@redhat.com>
Commit 4bbeec134a "fixed" an old
terminology confusion about keyid vs fingerprint, but in the process
broke pgpPubkeyFingerprint() for any external callers, as it now only
feeds on decoded packets whereas before it did the decoding by itself.
Add the decoding step back to the public function to make it usable outside
rpmpgp_internal.c again, retrieving a fingerprint seems like an useful
(public) API to have.
This is kind of a regression fix in that prior to commit
4bbeec134a pgpPubkeyFingerprint() returned
meaningful data to the outside caller and afterwards it didn't, however
that commit broke the API anyhow so it's kinda complicated.
Maybe we should just call it a bugfix and be done with it.
Related to #1549
1cdb72ae48
introduced a change where triplets that rpm doesn't know about
are rejected, which in turn causes a regression for users like
Yocto that explicitly use them.
In particular, x32 is a 64 bit x86 ABI with 32 bit pointers and
is supported via settings in custom /etc/rpmrc:
arch_compat: qemux86_64: all any noarch x86_64_x32 qemux86_64
When `rpmkey --import` is given a partially valid key, it may emit
warnings, which are backend dependent. This is currently the case
with the Sequoia, but not the internal OpenPGP parser.
The lints make the tests more fragile. Moreover, the tests aren't
checking the warnings, but other behavior. Suppress the warnings by
passing `--quiet` to `rpmkeys`.
Fixes#2071.
Hack to allow suppressing key import lint warning messages. Emitting
warning messages depending on verbosity level is ugly but for the case
at hand (different output between PGP backends on CI) it's probably the
lesser evil here.
Initial patch by Neal H. Walfield.
An OpenPGP subkey shouldn't be checked for validity when imported, but
when it is used, e.g., when checking a signature's validity. This is
because a key's validity partially depends on the current time.
The internal OpenPGP implementation checks for validity when the key
is imported; other implementations should not do this. This means
that the output of two tests (268, 'rpmkeys --import rsa (rpmdb)' and
273, 'rpmkeys --import invalid keys') have different output depending
on whether the internal OpenPGP implementation is used or the Sequoia
backend is used.
Use AT_CHECK_UNQUOTED instead of AT_CHECK, and the selected backend to
customize the expected output.
Fixes#2062.
The key to understanding `%bcond_with` and `%bcond_without` is that these
options *create command line switches* and unless the user thinks in those
exact terms, there's little hope of understanding them. Further, take
care to differentiate between option creation, enablement and defaults
in terminology and document `%bcond` version availability.
Fixes: #2150
If the repo is already initialized when calling this macro and it's
using a different branch name than "master" (see #2121) or the global
git option init.defaultBranch is set differently (see #2120), the macro
will fail at:
%{__git} branch --set-upstream-to=master
Instead of being overly clever, just track the original (start-point)
branch by using --track when branching (see git-branch(1) for details).
For brevity, combine this and branch creation into a single checkout
command.
This fixes commit 3a6b1d8fbf.
Thanks Panu for the clarification and suggestion in #854!
As per GNU glob(3), GLOB_ONLYDIR does not guarantee the matches are in
fact directories, that's why we check them with lstat(2).
That may lead to the match list being empty even after a successful
glob() run (rc == 0), so for consistency, return GLOB_NOMATCH in that
case, just like we would for a missing file.
No functional change since we don't check for the exact return code in
the callers, only whether it's positive or not.
Do set *argcPtr even if the actual count is 0, rather than leaving it
unchanged and thus possibly undefined in the caller. This is also
consistent with how glob(3) works.
Rather than listing all the rules, just refer the reader to the man
page. Although brace expansion isn't part of the standard rules, we
still support it through glob(3) with GLOB_BRACE, so make a note.
By definition, glob(3) matches pathnames on the file system, so no
pattern starting with a URL protocol (e.g. http:// or file://) will ever
produce any meaningful results when passed to it, it will just fail with
GLOB_NOMATCH.
This wasn't always the case, we used to call a custom Glob() function
here in the past, which knew how to handle URLs, but that was axed in
commit 9cbf0349b8 some 15 years ago.
To this day, however, we somewhat continue the legacy by letting
URL_IS_PATH (file://) patterns pass through glob(3) if they contain
magic chars, with the only possible outcome of failing afterwards. Drop
this special case and simply consider any known URL pattern as non-local
(int local = 0) and return it immediately. Also remove the no-op URL
code while at it.
Instead of constructing a new list from scratch and returning that, just
extend the passed list. This makes it easier to use this function
incrementally when expanding multiple patterns in a loop, such as during
package manifest parsing which we adapt here right away.
Preserve the ability to pass NULL as argvPtr and still get a match count
via argcPtr, by keeping the local argv around for that case.
No functional change.
Now that we directly use GLOB_NOMAGIC to implement a fallthrough for
non-glob patterns since commit 9e541c6a7d,
we may ironically end up subjecting such patterns to the lstat(2) check
at the end if they're directories, and thus possibly not return them.
While the actual impact on our codebase seems to be minimal, mostly in
terms of pushing the point of failure elsewhere and possibly printing a
different error message, for the sake of consistency with the idea of
GLOB_NOMAGIC, fix this by bringing back the short-circuit check.
While at it, make it a bit simpler than the original rpmIsGlob() by
leaving out the well-formedness check (i.e. if a bracket/brace has a
closing counterpart) as that's not what GLOB_NOMAGIC does either.
Remove the now unused next_brace_sub() as part of that.
to set a separate license to the source RPM. This can be useful if the
sources have code under additional licenses that do not end up in the
binary packeges.
Resolves: #2079
for unknown payload compression format. At this point it is unlikely
this isn't an RPM file as we detected the headers but much more likely
the package is using a newer compression format.
As the shell can't deal with null bytes only read two bytes and check
for proper match. This way we can match for the null byte even if it is
not part of the string.
This also silents the warning from the shell that there is a null byte
being ignored in the magic string for lzma.
This script converts binary header sizes to decimal numbers. Shell is
not that well suited for this task as it drops newlines at the end of
command substitutions. Add a . character at the end and strip it right
after that to avoid this problem.
Resolves: rhbz#1983015
With the SRPMs now containing the expanded spec file they are bound to
have the build root included in the header. Turns out some people
package SRPMs to rebuild them locally e.g. against the local kernel.
Resolves: rhbz#2104150
This is an incomplete release-early version, NOT intended or
suitable for production use. It is intended to replace the autotools
based buildsystem in rpm 4.20, until then it'll be developed alongside
it. This causes some extra complications of course, but then we avoid
a huge flag-day, and that matters more.
To those wondering why cmake and not ${myfavorite}: the community around
us effectively made that choice for us. We've made a lot of noise about
bootstrap dependencies. When libsolv, dnf and all the related stack is
powered by cmake build, it'd be just foolish to go with anything else.
This way people working on the rpm stack have only one build system to
learn, there's peer support available nearby and bootstrap dependencies
are reduced, not increased. It also doesn't hurt that cmake is actually
and actively maintained.
Panu Matilainen