When using --ignorearch or options that imply it (e.g. --printsrcinfo),
all checks of the arch array were skipped. Instead, perform all checks
apart from confirming that the package can be built on that
architecture.
Signed-off-by: Allan McRae <allan@archlinux.org>
Using gdb-add-index to add a .gdb_index section before splitting
debug info (together with enabling "maintenance set debuginfod
download-sections" in GDB) can dramatically reduce the amount of
data GDB has to download.
Fixes#205.
Signed-off-by: Allan McRae <allan@archlinux.org>
The current logic sets CCACHE_PREFIX to distcc when both distcc and
ccache are enabled. However, according to the source of ccache, it would
execute the command with execv, which would not look up arg0 from PATH,
unlike those exec functions with _p suffix.
This would result in the following error, when building a package with
both ccache and distcc enabled:
```
ccache: error: execute_noreturn of distcc failed: No such file or directory
```
This breaks package builds in different ways: packages that use make/cc
directly would yield the actual error which is the same as the above
line, packages that rely on other build systems wouldn't go through
compiler check and complain on a bad compiler.
To reproduce the problem, try to build a simple package:
```
git clone https://gitlab.archlinux.org/archlinux/packaging/packages/abc.git
cd abc
cp /etc/makepkg.conf .
echo 'BUILDENV=(distcc color ccache check !sign)' >> makepkg.conf
makepkg --config makepkg.conf
```
refs:
f887434d35/src/ccache/execute.cpp (L348)https://man.archlinux.org/man/exec.3.en#v_-_execv(),_execvp(),_execvpe()
Signed-off-by: Guoxin Pu <pugokushin@gmail.com>
Repeated values in the arch array can result in architecture specific
fields being repeated when using --printsrcinfo.
Signed-off-by: Allan McRae <allan@archlinux.org>
The check for the format of the PACKAGER variable did not align with the
rest of the function where it was located. Move to its own function.
Signed-off-by: Allan McRae <allan@archlinux.org>
We use NPROC for managing the number of parallel jobs to run, so it is
essentially that this is a valid number. Add a lint pass, and move the
setting of the default value to this location.
Signed-off-by: Allan McRae <allan@archlinux.org>
Parallel processing of file stripping is causing a TOC/TOU race when copying
source files into the debug location resulting in error messages from cp.
While hiding this error is not the ideal solution, it is currently the only
one we have. Given this is a error of our own making, and we understand the
cause and have determined there is zero actual downside to ignoring the
error, we will accept this approach until something better is found.
Signed-off-by: Allan McRae <allan@archlinux.org>
Perform file stripping in parallel where possible. Hardlinks remain
processed one at a time due to reproducibility issues.
Signed-off-by: Allan McRae <allan@archlinux.org>
Handle singly and muptiply hard-linked files separately. Also collect
information on hard linked files to avoid searching the entire package
to check for hard links.
Signed-off-by: Allan McRae <allan@archlinux.org>
Add a "safe_" prefix to strip_file() and strip_lto() to indicate that
these functions are taking extra steps to ensure permissions remain
unchanged.
Signed-off-by: Allan McRae <allan@archlinux.org>
Only a subset of checks were being performed on the overridden arch
arrays in package functions. Refactor checking such that all checks
are perform on all arch arrays.
Signed-off-by: Allan McRae <allan@archlinux.org>
The decision to set the PYTHONHASHSEED variable and its value is outside
the domain of makepkg and should be handled by a distribution. Move this
file to the libalpm-dropins project.
Signed-off-by: Allan McRae <allan@archlinux.org>
Debug symbols should only be split from finally linked ELFs, not bare
object files. We're already excluding static libraries from splitting
for a similar reason.
The `.gnu_debuglink` sections are also mishandled by LLVM's LLD, which
copies them to its output. For example, this affects Arch Linux's
`/usr/lib/Scrt1.o`.
While we're here (and it changes the code less), also strip GNU LTO data
from bare objects, again for the same reason we're removing it from
static libraries, and apply static library stripping instead of shared
library stripping.
See: https://bugs.gentoo.org/787623
When objcopy encounters an already-present section, adding the new
debuglink will fail with a warning. Remove any existing `.gnu_debuglink`
section to work around this problem.
Arch Linux's `rust` package is affected by this. Apparently when LLVM's
LLD links in `/usr/lib/Scrt1.o` it will also copy the `.gnu_debuglink`
section.
See: https://bugs.gentoo.org/787623
Using objcopy can result in file permission changes. We work around this
by using "cat" to copy the temporary output file into the target. Extract
this code into a utility function.
Signed-off-by: Allan McRae <allan@archlinux.org>
Git commands can fail in bare repositories when global git config contains safe.bareRepository=explicit.
Some users set this option for increased security.
To be compatible with this configuration, explicitly set safe.bareRepository=all when invoking git in a bare repository.
The Arch sharutils package was spewing messages about "Permission denied" when
copying source files into the debug package. This is due to the source files
having 444 permissions and being used in multiple binaries. Only copy each
source file into the debug package onces to avoid this error.
Signed-off-by: Allan McRae <allan@archlinux.org>
Supporting git source fragments (branch, commit, tag) is difficult in
conjunction with GITFLAGS usage - particularly with the most common
use cases that reduce the amount of data cloned from the upstream repo.
Leaving GITFLAGS in place an documenting that various git source features
are not supported when GITFLAGS are in used is not an ideal 'solution'.
Instead, remove GITFLAGS support.
Signed-off-by: Allan McRae <allan@archlinux.org>
This causes issues when repeatedly building a package using the same
git checkout. There is also ambiguity of the default checkout when
trying to build from HEAD. See #142 and #143.
This reverts commit 85c421f1cb.
Add a new error code to expose the 'not a clone of' error state of some source
providers (git and fossil). This allows other tools integrating further and
handle this specific error state.
One usecase evolves around frequently changing source locations in PKGBUILDs
of packages in the AUR.
We only really need debugedit while building the package, while this
check would run if you tried something like `makepkg --verifysource`.
Use the same checks as we have for fakeroot to wrap debugedit so we
don't beg for dependencies we don't need.
Fixes: 3ed08f97ec
Signed-off-by: Morten Linderud <morten@linderud.pw>
We use an extended glob here, but were relying on having it globally set
in makepkg. This causes it to fail when used in scripts.
Since scripts using libmakepkg may not want extglob to be set, save and
restore the environment while explicitly setting extglob only where we
need it.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
Bailing early caused problems with makepkg failing on verify but expired
signatures. As this is often out of the packagers control, and it is
better to verify a signature than not, we try bailing as late as possible
and let makepkg warn about the expired signature.
Signed-off-by: Allan McRae <allan@archlinux.org>
Guile 2.2 uses ELF format for its byte-compiled files. These are not
normal executables, and are not strippable in the normal sense.
Given these are ELF files and detected by "file" as non-stripped binaries,
it is only possible to skip these using the file path.
Fixes#73
Signed-off-by: Allan McRae <allan@archlinux.org>
Move the check for the `NEWSIG` metadata keyword contained in the
GnuPG based statusfile to `parse_gpg_statusfile()` so that it is also
run when creating the statusfile in `verify_file_signature()` and not
only when running `verify_git_signature()`.
Signed-off-by: David Runge <dvzrv@archlinux.org>
The output of
`gpg --quiet --batch --status-fd /dev/stdout --verify <signature_file> <file> 2> /dev/null`
or
`git verify-commit --raw <commit> 2>&1`
may contain binary data, if the signature has been created with an
OpenPGP implementation, that e.g. makes use of notations.
If the notation string (see `NOTATION_DATA` in /usr/share/doc/gnupg/
DETAILS) contains a trailing binary char, this will break signature
verification, as any following entry (e.g. `VALIDSIG`) will be offset.
As we are only making use of a narrow set of terms from the statusfile
(namely `NEWSIG`, `GOODSIG`, `EXPSIG`, `EXPKEYSIG`, `REVKEYSIG`,
`BADSIG`, `ERRSIG`, `VALIDSIG`, `TRUST_UNDEFINED`, `TRUST_NEVER`,
`TRUST_MARGINAL`, `TRUST_FULLY`, `TRUST_ULTIMATE`), we are applying a
filter, so that only understood terms are written to the file.
Signed-off-by: David Runge <dvzrv@archlinux.org>
Emit an early error message if tag or commit verification with git or
detached signature verification with gpg fails.
Make `verify_file_signature()` and `verify_git_signature()` return
non-zero in this case and set errors to `1`, so that later checks
in `check_pgpsigs()`, although still run, can not lead to a positive
result.
Signed-off-by: David Runge <dvzrv@archlinux.org>
.a files are not valid ELF files so we can't run objcopy nor debugedit
on them.
Rename STRIPLTO to STATICLIB to be more descriptive.
Signed-off-by: Morten Linderud <morten@linderud.pw>
Some projects might duplicate the file in multiple locations for one
reason or another. When debug packages are enabled, `makepkg` will only
strip the first occurrence of the binary and abort early on all the
other binaries.
Signed-off-by: Morten Linderud <morten@linderud.pw>
During a package build we call prepare_buildenv in multiple stages of
the process. For debug packages, one of the hooks is buildenv_debugflags
which populates the debug flags to the according variables.
The issue is that the behavior of the current implementation of
buildenv_debugflags is not idempotent, so consecutive calls will append
the same flags again. In certain cases this isn't an issue, however
for context aware build frontends like cargo any change of the build
inputs leads to a fresh build. This means that any invocation of such
a build ecosystem inside the package() function will trigger a full
rebuild, which is not desired.
To fix this issue, this commit makes buildenv_debugflags idempotent
by only appending flags once to the target variables.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
