| Age | Commit message (Collapse) | Author |
|---|
|
Simply pass options on to gpg the same way gpg uses them -- no looping
through and checking lots of signatures.
This prevents a situation where the signature file to be verified is
manipulated to contain an embedded signature which is valid, but not a
detached signature for the file you are actually trying to verify.
gpg does not offer an option to verify many files at once by naming each
signature/file pair, and there's no reason for us to do so either, since
it would be quite tiresome to do so.
In the event that there is no signature/file pair specified to
pacman-key itself,
- preserve gpg's behavior, *if* the matching file does not exist, by
- assuming the signature is an embedded signature
- deviate from gpg's behavior, by
- offering a security warning about which one is happening
- when there is an embedded signature *and* a matching detached file,
assume the latter is desired
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This doesn't do quite as good of a job of "hiding away" the real script
as we did with autotools, but it satisfies the need for being able to
run scripts which depend on libmakepkg with the local copy within the
repo. We do, however, improve upon the autotools script by ensuring that
the bash path used in configuring pacman is the interpreter used to run
the underlying script.
|
|
Provide both build systems in parallel for now, to ensure that we work
out all the differences between the two. Some time from now, we'll give
up on autotools.
Meson tends to be faster and probably easier to read/maintain. On my
machine, the full meson configure+build+install takes a little under
half as long as a similar autotools-based invocation.
Building with meson is a two step process. First, configure the build:
meson build
Then, compile the project:
ninja -C build
There's some mild differences in functionality between meson and
autotools. specifically:
1) No singular update-po target. meson only generates individual
update-po targets for each textdomain (of which we have 3). To make
this easier, there's a build-aux/update-po script which finds all
update-po targets and runs them.
2) No 'make dist' equivalent. Just run 'git archive' to generate a
suitable tarball for distribution.
|
|
Remove all remnants of library/{output_format,term_colors}.sh
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In the spirit of making libmakepkg more useful as a library, and,
critically, *using* that library for additional pacman scripts, we
should include all of output_format.sh and term_colors.sh directly in
libmakepkg and hopefully stop having to embed additional copies in e.g.
repo-add via m4 macros.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This behavior is confusing, since it means absolutely everything goes to
stderr and makepkg itself is a quiet program that produces no expected
output???
The only situation where messages should go to stderr rather than
stdout, is with --geninteg which is meant to return the checksums on
stdout (but we don't want to totally get rid of status messages when
redirecting the results elsewhere, or, worse, redirect status messages
to a PKGBUILD). For this specific case, redirect message output to
stderr in the --geninteg callers directly.
Implements FS#17173
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
- it comes with free collation when moving the LC_ALL declaration up a bit;
this fixes a bug where the .FILES were not being properly sorted and
their order depended on directory creation order, which broke
reproducible builds in the wild.
- it handles sorting null-delimited output everywhere, without sort -z;
this lets us get rid of sed hacks
- it is faster than invoking multiple find subprocesses
- dotfiles can be automatically printed *and the C locale sorts them first*
with a single ** glob
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We don't need exact package name completions for something that expects a
regular expression *search*, which is what we currently do. If you want
a package name completion for a search, you don't need the search.
This change is consistent with the current state of zsh completions.
Fixes FS#59965
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Filename completion should only be generated for makepkg, when using the
options -p or --config... which means we should offer option completions
by default.
Filename completion for pacman, should not be generated when using -Qu,
or -F without -o.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
[[ ${array[@]} ]] will resolve to false if array only contains empty
strings. This means that values such as "depends=('')" can be inserted
into a pkgbuild and bypass the linting.
This causes makepkg to successfully build the package while pacman
refuses to install it because of the unmet dependency on ''.
Instead check the length of the array.
Signed-off-by: morganamilo <morganamilo@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
SIZECMD was replaced in 1af766987f with a POSIX solution, and this token
is no longer used/needed.
|
|
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
lint_pkgver returns 0 if PKGVERFUNC, since it's likely that update_pkgver()
will change the value of pkgver anyway, and there's no point in linting the
old value. update_pkgver() will call check_pkgver() itself to validate the
new value.
However, that "optimization" only holds if we're definitely going to call
update_pkgver() later; and that's way more complicated than
if (( PKGVERFUNC )); then
it's more like:
if (( !GENINTEG && !PACKAGELIST && !PRINTSRCINFO && !SOURCEONLY && !REPKG && PKGVERFUNC )); then
Which is to say: If I have a PKGBUILD with pkgver():
* if I run `makepkg -g` I expect it to lint pkgver, but it won't
* if I run `makepkg -R` I expect it to lint pkgver, but it won't
* ...
So let's fix that.
Rather than try to keep a huge list of conditions in sync with the flow of
makepkg.sh.in, let's just drop it. As far as I can tell, the only thing
that skipping lint_pkgver() really enables is letting the PKGBUILD author
write `pkgver=` in the initial version, and letting pkgver() fill it in.
They can just start writing `pkgver=0` for that workflow.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We accept package_foo() in non-split packages, because it's easier to
switch to/from a split package just by removing a pkgname element. But
it makes no sense to have both in one PKGBUILD.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Due to a copy-paste error when initially implementing this, it actually
uses a duplicate function name, usually resulting in lint_pkgbuild
overwriting the function definition.
Then the PKGBUILD lint gets run twice, one time before the PKGBUILD is
even sourced -- to potentially surprising results, like erroring out on
a pre-existing shell definition that doesn't match our expectations.
Seen in the wild with lint_config triggering an error for
'declare -x arch="foo"'
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We don't need to translate the "Copyright YEAR AUTHOR" part, no part of
it should probably be translated and it definitely shouldn't turn every
single license terms notice into a separate translation just because the
author/year is different.
Fixes FS#58452
Also consistently add a blank line after the copyright and before the
license terms.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This reverts commit 9cdfd18739cc4b0e2b2efeb9a92a3ea612c8505f.
We've never documented whirlpoolsums support in the manpage and no one
really seems to have realized we support it, let alone use it -- except
for a few parabola packages, being the contributor's motivation for
adding support.
The problem is that for two years the code has been broken. In commit
577701250d645d1fc1a505cde34aedbeb3208ea5 we moved to coreutils to
provide checksum commands, rather than openssl, but there is no
whirlpoolsums binary.
Properly fixing this would require re-adding a dependency on openssl,
independent of the libalpm crypto backend -- which defeats the purpose
of moving to coreutils in the general case. nettle-hash does not provide
a whirlpool algorithm any more than it does base64 (the original reason
for moving to coreutils).
Therefore, we should just drop support for this again.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
It's most likely a case where output is being captured, so we shouldn't
be interleaving status messages with function output regardless. Setting
the pkgver() status message (the one time we use it in a subshell)
separately also makes it safe to change whether message.sh functions write
to stdout or stderr.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
`run_function_safe pkgver` is evaluated in a subshell and therefore does
not abort when it should. Explicitly check the return outside of the
subshell and abort if necessary.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Both run_function and run_function_safe will save and restore `shopt -p`
but the former is only called from the latter. It makes sense to save
this as part of a "safe" runner, so let's just do it in one place, there
where we save and restore everything else too.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
When re-running makepkg for fakeroot, if `bash -x makepkg` was used this
is lost. Fix by encoding the current set of options explicitly in the
invocation, both for makepkg and for the wrapper used to test scripts
inside the source tree.
Also change to use ${BASH_SOURCE[0]} instead of $0 as the latter can be
anything the parent process wants, while the former is explicitly set by
bash itself to the filepath of the script.
See http://mywiki.wooledge.org/BashFAQ/028
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Pull out the expected=y/n check into a separate function and make use of
the fact we can just prepend the fallback arrays to get the same result.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Now that we require bash 4.4 this is "more correct" than analyzing the
output of declare -p to see if it compares favorably with -a.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit c6b04c04653ba9933fe978829148312e412a9ea7 the signing function
was moved out of fakeroot, and thus out of the create_package loop. This
meant that if package signing failed, it was no longer possible to tell
which package it failed on by checking which package creation is
currently running. Successful signing attempts do not have this problem
as we already printed the name of the signature file.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: morganamilo <morganamilo@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This causes package_$pkgname() to be preferred over package() in the
non-split case, but the behavior if both functions exist was
undocumented anyway.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Adds opt-in lz4 compression of *pkg.tar files with makepkg.
This is nice to have as an option for very fast compression
and is already installed with libarchive.
Signed-off-by: Alex Butler<alexheretic@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Default to the standard completionsdir, which is lazy-loaded, rather
than hardcoding the compatdir which is not.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
The biggest issue is directly supplying the data within the format
string which can result in misinterpreting formatter sequences if a
printed variable contains an "%" in it. This character is currently
permitted in the pkgver field, though not in the pkgname. Also
pacman/libalpm itself has much looser limitations and this can appear
anywhere at all if a package was created by some other program.
For the package "iambroke-1%s-1-any.pkg.tar.xz", installed in the build
environment, the result is:
-> Generating .BUILDINFO file...
awk: cmd. line:3: (FILENAME=- FNR=1085) fatal: not enough arguments to satisfy format string
`-1%s-1'
^ ran out for this one
Followed by a .BUILDINFO which contains an LC_ALL=C sorted list of
$pkgname-${epoch:+$epoch:}$pkgver-$pkgrel-$arch ending in:
installed = iambroke
Which is cut short, then fails to list the succeeding packages. The
package itself successfully builds.
It's also unnecessary to save the output of pacman -Qq in order to get the
information for pacman -Qi, since the latter will, just like the former,
return information for all installed packages if not given a package
name(s).
While I am at it, pipe this directly to awk rather than keeping a copy
in an unnecessary local variable. This is slightly more efficient in
addition to preventing the <<< herestring from re-interpreting the
content of "$pkginfos" in ways that don't really matter for our usage.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This change was introduced to prevent entries like depends=('foo>').
However, it had the unintended side effect of causing a number of
working PKGBUILDs to fail to build. This happened when a PKGBUILD
defined one variable through calling a "complex" statement within the
PKGBUILD's package function (e.g. a function or evaluating in a
subshell), then used it to define the package metadata variable.
extract_function_variable() cannot execute the package function in order
to retrieve this information, so it performs a simple grep + eval instead
and in the process misses the contextual awareness of running within the
package function.
While not catching these "issues" can result in incorrect SRCINFO, the
resulting packages are fine. Stop aborting on the common case where the
pkgver of a dependency is dynamically set during the package function
until the large number of broken PKGBUILDs are fixed, and the
restrictions of the PKGBUILD format are documented.
"Fixes" FS#58776
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
A blank file slipped into libmakepkg in commit 2c94118d.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
DW_AT_comp_dir is meant to contain the directory in which the compiler
was run
DW_AT_name contains the source file the compiler was told to use.
In the event that DW_AT_name is an absolute path, it is (obviously) not
meant to be computed relative to DW_AT_comp_dir. However, we did not
handle this correctly, and as a result tried to copy source files using
doubled-up filepaths.
The correct approach should be to use DW_AT_name on its own, in the
event that it is an absolute path.
See http://wiki.dwarfstd.org/index.php?title=Best_Practices.
This fixes debug package generation for many packages that use absolute
paths in their build systems... like CMake.
Reported-by: Jagannathan Tiruvallur Eachambadi <jagannathante@gmail.com>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This reverts commit 9e52a36794552b77ecf26f7f34b226d096978f1e.
The change to use declare for the split package metadata backup/restore
resulted in variables being declared at a local scope. When these variables
were unset (mostly noticed with debug packaging) this left the variable at
global scope defined. Revert back to the known good state.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit 9a4d61622066d5d30c649f1c958b26526a4ceddf debug packages were
merged into one exclusive pkgbase-debug, but the print_all_package_names
function did not get updated to match this logic.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Commit 9c8d7a80 broke the signing of debug packages by merging code up but
not changing the test condition.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Assuming that everything is a string leads to code which is effectively:
a=
a+=('bar')
This creates an array with 2 elements instead of one. Using proper array
initialization fixes this.
https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022591.html
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: morganamilo <morganamilo@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
When comparing the $BUILDDIR to the $startdir, we used string equality
instead of testing whether they are the same location, and ended up
appending $pkgbase even though there's no reason to use it here.
In some cases, this could result in makepkg erroring when trying to
create $srcdir/$pkgdir, if a file with the same name as the $pkgbase
exists. This is expected behavior if a file "src" or "pkg" exists, but
decidedly less so for $pkgbase.
This could be fixed either by setting $startdir to an absolute path, or
by ensuring the test checks this directly; I've chosen to do both, since
the test should really be correctly checking the thing it actually cares
about, but since we ensure absolute paths are used everywhere else, this
might bite us elsewhere someday. It's also more consistent.
Fixes FS#58865
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
It's especially dangerous in trap handlers since the return value of the
function becomes the return value of the last command before the trap,
not the last command in the current function. This applies to any
function executed in a trap handler, nested functions included.
In one case, install_packages failed (via return 14), which was inside a
conditional that then ran exit 14, which triggered the EXIT handler,
which called clean_up, which called remove_deps, which had !RMDEPS and
thus returned. The return value of remove_deps became the return value
of install_packages, triggering the ERR handler, which (due to another
problem) was still the user function handler, which then printed a
misleading error message and overrode the exit code with 4.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit 8ff03868a37b1f9c447784ae2fd639a49e426399 PACMAN_OPTS was
turned into an array. Unfortunately, that array was generated by
treating the "--color never" option as one string, instead of an
array of two strings...
Fixes FS#58820
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
$restoretrap is empty if the trap was not set. This caused the trap
handler to remain and override later exit codes.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We fail with an error, but then we also fail with:
==> ERROR: depends is not allowed to be empty.
/usr/share/makepkg/lint_pkgbuild/pkgname.sh: line 39: continue: only meaningful in a `for', `while', or `until' loop
During the refactor to provide enhanced pkgname=pkgver linting, this was
moved out of the ${pkgname[@]} loop to a distinct function, at which
time it should have been modified to return rather than continue.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit d8717a6a9666ec80c8645d190d6f9c7ab73084ac the write permission
checks were refactored. Initially we intended to drop this chmod in the
process, but due to some confusion about whether it was needed, I ended
up submitting patches both to preserve and to remove it... but it's not
needed after all. We do it on the individual $srcdir/$pkgdir, later on.
Then, we used the wrong version, which causes unnecessary restrictions.
See FS#58790
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
pacman accepts these, and there is no good reason to be more restrictive
ourselves; we should follow the example of "depends" here.
Update the documentation to actually state that this is supported.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Simplifies the function a bit, but mostly, mkdir -p will never fail if
the directory exists, and therefore makepkg never checks to see if it is
actually writable. On the other hand, it's unnecessary to check if the
directory exists once we know mkdir -p succeeded...
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|