| Age | Commit message (Collapse) | Author |
|---|
|
If you have a malformed pkgrel, the error message says that it must be a
"decimal". That isn't quite true, as that would mean that `1.1 == 1.10`.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
opt)depends/provides/conflicts
Given the depends
depends=('foo>=1.2-1.par2')
and the error message
==> ERROR: pkgver in depends is not allowed to contain colons, forward slashes, hyphens or whitespace.
One would be lead to believe that the problem is that they gave a pkgrel in
depends at all, not that the pkgrel contains letters.
Each of the (check,make,opt)depends, conflicts, and provides linters use a
glob to trim off properly formed epoch an rel from the full version string,
and pass the remainder to check_pkgver(). This does a good job of
accepting/rejecting full versions, but doesn't do a good job of generating
good error messages when rejecting if it's because of the epoch or rel.
1. Factor out check_epoch() and check_pkgrel() from lint_epoch() and
lint_pkgrel(), similarly to check_pkgver().
2. Add a check_fullpkgver() that takes a full [epoch:]ver[-rel] string and
splits it in to epoch/ver/rel, and calls the appropriate check_ function
on each.
3. Use check_fullpkgver() in the {,check,make,opt}depends, conflicts, and
provides linters.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Checking the length of the variable to be non-zero before considering it
an error is inconsistent; license=() and depends='' and `declare arch`
should be considered just as wrong.
In fact the current check detects depends='' as non-zero and returns an
error, but happily considers the others to be perfectly okay.
A more reliable check is to simply see if the name has been declared
(whether it is set or not), and then enforce that it's been declared to
the right type.
As an added benefit, avoiding the creation of proxy-evaled variables to
count the number of indexes results in simpler code.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit d8ee8d0c99c3820951e2e49dbdb71a5390bd1dc4 we made use of
fakeroot absolutely mandatory, and disabled a lot of the code which
checked to see if this now-defunct BUILDENV option was set, before
setting up the environment to use fakeroot. Unfortunately, we missed one
spot.
The check_software routine still checked to see if fakeroot was
enabled, but due to the option being removed, thought that it was in
fact disabled, and as a result this check would never run.
Fix by checking to see if we are trying to build either a package or a
source package, and if so, checking for fakeroot. These are the only two
situations where fakeroot is needed.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
There are state variables for everything else, and we use them to do
conditional checks on things, but it's currently a bit difficult to test
whether a package is being built, as it's the default action if *no*
options are specified.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Causes it to be reset (to $pkgdirbase/$pkgbase) between subpackages.
This shouldn't be visible.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Merge the similar code handling unsplit PKGBUILDs and individual
packages in a split PKGBUILD and make it a new function.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We don't need to re-backup the variables we restored on the previous
iteration.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Our sed parser for xdelta3 headers will greedily match on ":" which
coincidentally is also the character we use to define a version with an
epoch.
While we are at it, simply use sed for the whole pipeline, rather than
using both grep and sed.
Fixes FS#61195
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
We have code in order to remove deltas when removing a package, but it
is never run, since we try to remove the wrong file.
This was broken in commit cb0f2bd0385f447e045e2b2aab9ffa55df3c2d8a which
modified the internal layout we use to modify the db, changing "tree" to
"db", but did not update all locations where it was used.
This worked swimmingly well as long as only repo-add updates were
handling the backup and restore of the delta file, as the delta file
therefore got backed up to the correct location (db) in the shared
db_remove_entry() function.
But later on in the repo-remove logic, we tried removing a different
file that will never exist (tree).
Fixes FS#53041
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
directories are created by install_dir within the subdir custom_target
installation targets.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Simply fix a typo: in written -> is written
Signed-off-by: Michael Straube <michael.straube@posteo.de>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Elsewhere, we return 1 if a library dropin fails, and when running
functions in a loop, we use `|| ret=1` to preserve scope. This ensures
the return value of the function remains useful in isolation. Do the
same thing here as well.
Drop trivial function which wraps a dropin that also uses $ret, since
it's no longer needed.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Now that repo-add uses libmakepkg, it needs to have $LIBRARY set before
testing it in-tree.
[Allan: fix "make distcheck"]
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Instead of assuming all scripts are .sh.in and leaving a comment to that
effect, just take the input file directly.
This depends on the first dependency for the target being the source of
the script.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
All of our scripts depend on the same pattern .sh.in, and since commit
b5d62d2c91a2caf5c18945921cdf12af6f36b2d4, they also all (not just
makepkg itself) depend on libmakepkg.
There's no real reason to include separate targets for them just to
establish dependency rules.
While we are at it, fix a longstanding bug where generated wrapper
scripts did not depend on wrapper.sh.in (which due to moving to .lib,
requires we regenerate the script too), by making the shared target
pattern depend on it. All our generated scripts now require the wrapper,
even repo-add which now uses libmakepkg.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
repo-remove and repo-elephant don't care whether repo-add.sh.in is
updated... but they do require the repo-add target to be up to date, so
use that instead. As a bonus, use the same rule for both of them.
|
|
This opens the door for third parties to provide libmakepkg
extentions for the purpose of altering the build environment.
Signed-off-by: Que Quotion <quequotion@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This opens the door for third parties who provide extensions to
libmakepkg to supply scripts that confirm the presence of their
dependant executables.
Signed-off-by: Que Quotion <quequotion@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
|
|
If a user has a makepkg.conf policy to enable debug builds, but a
PKGBUILD has disabled buildflags, we would unset the *FLAGS but then
later append the debug *FLAGS anyway, which would result in some *FLAGS
being used, against the wishes of the PKGBUILD author.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This was only ever used by paccache, and paccache has since been moved
to pacman-contrib.
|
|
makepkg-template is a perl script and doesn't get wrapped by our shell
wrapper. It (wrongly) reads from the host machine rather than the build
root, but this is working as implemented.
|
|
Currently this prints the following message:
==> Extracting database to a temporary location...
==> Extracting database to a temporary location...
This redundancy is potentially confusing and may cause people to think
something is wrong. Historically, this message came from a time when we
only extracted one database, but repo-add was changed to always create
the files database in commit cb0f2bd0385f447e045e2b2aab9ffa55df3c2d8a
and whole code block with message intact was moved into a for loop and
run (and printed) twice.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
The respective write_* functions are low-level and shouldn't be
outputting statuses; move these to the logic flow where they are used.
This ensures the functions can be used in the future wherever, and also
solves an issue where, as fallout from the message.sh retrofitting in
commit 882e707e40bbade0111cf3bdedbdac4d4b70453b, the statuses got
redirected to the actual files.
The resulting package was technically correct, except that it contained
useless lines which pacman ignored, and repo-add also ignored but at the
same time generated an error message:
/usr/bin/repo-add: line 335: declare: `=-> Generating .PKGINFO file...': not a valid identifier
Thirdparty package tools with stricter parsers may abort with errors,
and "repose" is known to do so.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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>
|
