parseopts is used in makepkg and other scripts such as pacman-key as a
getopt replacement.
Instead of including it in those scripts via a macro, move it to
libmakepkg/util/parseopts.sh and have scripts source this file where
appropriate.
To keep the parseopts test, a new variable was introduced:
PM_LIBMAKEPKG_DIR
Signed-off-by: Alad Wenter <alad@archlinux.info>
Signed-off-by: Allan McRae <allan@archlinux.org>
In order for the scripts to be used in testsuites, it is easiest to generate
all of them so they are found in the build directory (which may be different
to the source directory).
Signed-off-by: Alad Wenter <alad@archlinux.info>
Signed-off-by: Allan McRae <allan@archlinux.org>
makepkg-wrapper did not get rebuilt if makepkg was regenerated due to library
changes. Ensure makepkg-wrapper is always generated and linked any time
makepkg changes.
Signed-off-by: Allan McRae <allan@archlinux.org>
We checked for empty array elements, but did not catch empty array. Add
a check for that case as well.
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Allan McRae <allan@archlinux.org>
The people who believe that pacman-optimize is actually doing something
useful are the same people who are voting for Trump.
Signed-off-by: Allan McRae <allan@archlinux.org>
This fixes the issue with --printsrcinfo that all arch specific variants
of a variable get merged into their non arch specific variant.
The .SRCINFO file ends up having $depends containing $depends_x86_64
and omitting the latter.
Signed-off-by: Allan McRae <allan@archlinux.org>
`makepkg -g` looks for existing checksums in the PKGBUILD file, so that
it can generate new sums of the same type. Previously it only checked
variables of the form "sha256sums", and not "sha256sums_x86_64". That
meant it would always fall back to MD5 for packages with only
architecture-specific sources. This change makes it look at
architecture-specific checksums too to determine the type.
Signed-off-by: Jack O'Connor <oconnor663@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
pacman expects an unarmored signature. makepkg forces the generation of
unarmored signatures, and repo-add will reject any armored signature.
For consistency pacman-key should also reject armored signatures.
Signed-off-by: Allan McRae <allan@archlinux.org>
The current way of extracting key trust from output of gpg --verify is not very
robust against changes in the format of said output. As a result, pacman-key
can return an error even if the signature is actuall good.
This change relaxes the regexp when parsing output of gpg.
Signed-off-by: Leonid Isaev <leonid.isaev@jila.colorado.edu>
Signed-off-by: Allan McRae <allan@archlinux.org>
This is a requirement to split the preparation of the build environment
into libmakepkg, which will allow dropping in extensions (e.g. to allow PGO).
After this patch, disabling buildflags or makeflags and enabling debug
CFLAGS will only effect the build(), check() and package() functions. The
relevant variables are no longer exported for the prepare() function. This
should have zero impact for the prepare() function of a properly written
PKGBUILD, as no building/linking is done there...
Signed-off-by: Allan McRae <allan@archlinux.org>
Using "-exec command {} +" systax exits on any error. Such errors occur when
running rmdir on a non-empty directory. Switch to "{} ;" syntax instead which
avoids exiting before the find command is completed.
Fixes FS#48515.
Note, we can not use "-empty" in the find command because it is not supported
by Busybox find, and the "--ignore-fail-on-non-empty" flag for rmdir is not
available on BSD rmdir variants.
Signed-off-by: Allan McRae <allan@archlinux.org>
These options were added before libmakepkg allowed passes like this to be
dropped in. I prefer only real core packaging tasks to be included in
makepkg and additional things like this to be dropped in by a user or
distribution that wants to support them.
Signed-off-by: Allan McRae <allan@archlinux.org>
This happened to work for the majority of cases because the only calling
function used a variable named "i" that was related to the variable being
passed to the function.
Fixes FS#48340.
Signed-off-by: Allan McRae <allan@archlinux.org>
This is partial revert of 8454daa7fe (makepkg: run pkgver() and
prepare() with --noextract).
Reasoning for the reversion (copied from FS#43498):
Running prepare() when --noextract is used no longer allows running
'makepkg -o && makepkg -e' with any PKGBUILD that applies patches in
prepare(). [1]
Sure there's --noprepare which restores the old behavior, but that's
a lot of extra typing for what I believe is a much more common use
of --noextract.
For OP's use case of doing git bisects, you can specify the commit
in the source array and thus skip --noextract since makepkg will
checkout the correct commit each time.
[1] I often extract the sources using 'makepkg -o', manually edit
some source files, and then use 'makepkg -e' to package it (while
possibly repeating the edit/package steps).
Signed-off-by: Allan McRae <allan@archlinux.org>
This avoids introducing unnecessary changes to the time stamp into
package repositories that regularly use --printsrcinfo to update the
.SRCINFO file.
Signed-off-by: Allan McRae <allan@archlinux.org>
This reverts commit f9423cfa5d.
This created issue when building packages with debug info multiple times.
It could be fixed, but it confirmed my initial opinion that keeping other
directories in $pkgdirbase was wrong. Use different BUILDDIRs if you want
to build different things from a single PKGBUILD.
Commit 663c74150a
(makepkg: merge arch dependent variables after PKGBUILD linting) broke
"makepkg -g" on a PKGBUILD which did not include the current architecture, by
moving the lint_pkgbuild call before GENINTEG was processed.
Fix that by setting IGNOREARCH for the "-g" option.
Signed-off-by: Allan McRae <allan@archlinux.org>
Extract array detection into its own utility function that ensures
extglob is enabled.
Suggested-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Most entries in $sources contain variables so finding out why a URL
fails to download is hard because one has to manually replace the
variables when looking at the PKGBUILD. Simply output the full URL here
so that it can be easily seen what is wrong.
Old:
==> ERROR: Failure while downloading example-1.2.4.tar.gz
New:
==> ERROR: Failure while downloading http://example.org/releases/1.1/example-1.2.4.tar.gz
With the new format it is much more obvious that the directory name is
the culprint (1.1 vs 1.2) while the old one would not display that
information.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Allan McRae <allan@archlinux.org>
Modifications made to the source before running with --noextract may alter
the version string returned by pkgver(). Always run this function if present
and check build status before proceeding. Fixes FS#46800.
Also run prepare() when --noextract is used (unless --noprepare is specified).
Signed-off-by: Allan McRae <allan@archlinux.org>
This information can be used to reproduce build conditions, which can then be
used to determine if a package builds reproducibly.
Signed-off-by: Allan McRae <allan@archlinux.org>
Approach the detection of variables of the wrong type using an approach
similar to that used for construction of .SRCINFO files. While doing silly
things in bash could still result in false negatives, this approach should
be very robust to generatinf false positives results.
Signed-off-by: Allan McRae <allan@archlinux.org>
Negative subscripts to indexed arrays are not supported before 4.2. However,
since substring expansion works on arrays, we can specify an offset of -1 to
be taken relative to one greater than the maximum index of the specified
array (see Parameter Expansion section of the bash man page). This works with
both Bash 4.1 and 4.2, and 4.1 is already the oldest supported by pacman.
Signed-off-by: Aaron Campbell <aaron@monkey.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
run_split_packaging did not preserve the $pkgname array correctly, and
would create duplicate entries in the list during restore.
After restoring the backup (a b c) would become (a b c b c).
This probably went unnoticed because during --install, pacman would
reconcile the duplicates.
Signed-off-by: Allan McRae <allan@archlinux.org>
