| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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.
|
|
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>
|
|
[[ ${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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
file 5.33 introduces a new MIME type "application/x-pie-executable",
which is used for relocatable binaries. makepkg ignored these binaries
and did not attempt to strip them.
Handle the new MIME type like the old "application/x-sharedlib".
Stripping the binaries with --strip-unneeded to keep relocation
information should be the correct thing to do.
file 5.33 also misidentifies actual libraries as PIE executables, so we
didn't strip any shared libraries, either. We now work around this bug.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Checking the file extension to determine if something is a signature is
currently done in three places:
- verify_file_signature: uses $file to print status, reuses it for
comparison
- source_has_signatures: uses $netfile, but removes url component if
filename component exists
- generate_one_checksum: uses $netfile and fails to detect renamed files
This leads to inconsistent behavior when trying to use a signature of
the form "foo-1.0.tar.gz.asc::https://example.com/foo-1.0.tar.gz.pgp"
Fix this by treating the third case like the second case.
Reported-by: Giancarlo Razzolini <grazzolini@archlinux.org>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Since bash 4.1 extglobs can be used within [[ ... ]] regardless of
whether the shopt is set. Our configure.ac requires bash 4.1.0 at a
minimum for pacman scripts.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
micro-optimization: We only care about temporarily enforcing extglob, so
that is the only one we need to explicitly restore.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
depends=(foo=$epoch:$pkgver-$pkgrel)
In commit 91b72cc386ca03241791748da5da2b150c724ace support was added for
linting depends/etc. to ensure they contain only valid dependency
specifiers. However it did not properly take into account the
possibility of dependencies linked to a specific pkgrel or epoch, which
promptly failed to build because "-" and ":" is not allowed in a pkgver.
pkgrel is something supported by pacman and useful for e.g. split packages
which cannot be mismatched even if the pkgver is the same. Fix by
removing an optional suffixed "-$decimal" when checking for a valid
pkgver.
epoch is kind of difficult to do without :D so likewise fix by removing
an optional prefixed "$integer:"
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Some scripts are using `break 2` to break out of the option parsing
loop.
Since a single `break` is sufficient in these cases, remove the extra
argument.
Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
depends, provides, conflicts, replaces, and other variables that are
meant to contain package names, are now checked to ensure
1) the name component contains only characters that would equate to
a valid pkgname.
2) the version component contains only characters that would equate
to a valid pkgver.
3) comparison operator is a valid comparison operator (e.g. provides
only allows exact = while optdepends doesn't allow anything)
This also refactors pkgname into a shared utility function, wires up
pkgbase optdepends and provides to use it, and gives pkgver a touchup
to allow referencing where it was called from.
Fixes FS#57833 and a bit of extra.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
print_all_package_names used in_opt_array to check whether or not the
PKGBUILD itself has options=('debug' 'split') -- while checking to see
if it was enabled per split package which doesn't make sense as these
options apply globally. This prevented debug packages from being listed
if enabled via makepkg.conf rather than per PKGBUILD.
Instead, use check_option to determine whether makepkg actually thinks
it is meant to try creating a split debug package.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Currently the only things we check are:
- Things that should be arrays, are not strings, and vice versa (this
was mostly copy-pasted from the similar code in lint_pkgbuild).
- Variables that are meant to contain pathname components cannot contain
a newline character, because newline characters in pathnames are weird
and also don't play well with future changes intended for the
--packagelist option.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit c6b04c04653ba9933fe978829148312e412a9ea7 package signing was
moved out of fakeroot, and as part of this process, the global pkgname
variable was modified in order to extract the built package names.
However, if a debug package was not available and added to the list of
packages, the function was aborted early, before the pkgname array was
restored, thereby corrupting the later stages of makepkg and
specifically the install_package function which needs to know which
pkgnames to install.
Fix this by inlining the debug package signing inside the `if` check,
and as added security switch to using `for pkg in "${pkgname[@]}"` as is
done in many other parts of makepkg, since package signing does not
depend on the value of pkgname for anything.
Additionally, since debug packages may not actually exist, check if the
package file exists first.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Followup on c6b04c04653ba9933fe978829148312e412a9ea7 which refactored
the signing function to run outside of fakeroot, and in the process
moved the status message to outside the $SIGNPKG check.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Additionally provide a separate error for failure to create the
directory vs lack of write permissions on a pre-existing directory.
This also means we now consistently try to create any nonexistent *DEST
directories as needed before aborting with E_FS_PERMISSIONS. Previously
only $BUILDDIR received that kindness.
Fixes FS#43537
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
make update-copyright OLD=2017 NEW=201
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In order to detect if pkgver contains whitespace, we need to quote it.
Previously, only the characters up to the first whitespace was checked.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Currently this seems to be only theoretically useful. The most likely
reason for wanting a packagelist is in order to script makepkg and
derive the filenames for the packages we want to install or repo-add,
but in the current implementation this requires a lot of additional
post-processing which must be duplicated in every utility to wrap
makepkg.
- It is of minimal use to know what packages might get created on some
other device utilizing a different CPU/OS architecture, so don't list
them.
- It is non-trivial to reimplement makepkg's logic for sourcing any of
several makepkg.conf configuration files, then applying environment
overrides in order to get the PKGDEST and PKGEXT, so include them
directly in the returned filenames.
- Output is delimited by newlines, for readability. For maximum
parsing reliability, libmakepkg needs to learn how to lint the PKGDEST
and PKGEXT variables to ensure they do not contain newlines, which
will be submitted in a separate patch.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Commit 8bec63bf92d8dd028aa88dbd5109c314cdb9ebea attempted to switch to
using -fdebug-prefix-map to set file locations in debug packages. It
make a few mistakes...
1) Adding debug C{,XX}FLAGS only worked if DBGSRCDIR was defined in
makepkg.conf. Fix this by falling back to the default value.
2) Using -fdebug-prefix-map altered a lot of assumptions about file
locations when copying source files into debug packages. This resulted
in lots of messages of failed cp in packaging output.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In eaa82b4d0775252856a4e54a6f2a9ea191cf0b8f source_has_signature() was
modified to check if git repositories are marked as signed. However, due
to a typo the unused variable $netfile was checked. This worked as long
as the last source element was marked as signed, due to $netfile being
mistakenly set as a global in check_vcs_software(), but usually failed
with multiple sources.
Break this more consistently by properly declaring $netfile as a local
variable in check_vcs_software() which it should be regardless. Fix it
again by completely moving over to $netfile in source_has_signature()
as netfile is more descriptive of the current state.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In 42e7020281d3ae260e1e9693495f527b7f476625 creating the gpg statusfile
for a source file was split into a separate function, which used the
return code to indicate unsigned files and proto-specific errors.
However, the fallback return code was set by the final gpg invocation,
which would be 1 if the signature was somehow broken (for example, the
key was not available in the gpg keyring). As a result makepkg thought
that file did not have a signature and skipped over it rather than
erroring out.
Fix this by explicitly setting the return code for all
verify_*_signature() functions.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit 8b0d59b83a60eb504567590346119fe4cd891cad support was added for
storing the source files of binaries in debug packages. This made use of
the debugedit program which is part of the RPM package manager, which is
not very standalone.
The same effect can be achieved using -fdebug-prefix-map, an option
accepted by both the gcc and clang compilers which modifies how the
compiler itself stores the references to the source files rather than
requiring us to later edit the produced binaries. This also removes the
dependency on external programs like debugedit.
As a result of this change, source files will only be effectively added
for programs which actually use the exported CFLAGS. This is a reasonable
tradeoff as we expect our CFLAGS to be used rather than ignored. Upstream
software which do not produce useful debug packages are expected to fix
their build systems to respect the environment CFLAGS.
As a result of this change, the routine for extracting source filenames
from binaries had to be modified to derive the source file from the
final debug location, rather than the other way around.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
In commit 8b0d59b83a60eb504567590346119fe4cd891cad support was added for
storing the source files of binaries in debug packages. Allow the user
to specify where those source files should be stored via makepkg.conf
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
This allows for more easily extending the list of allowed compression
methods, as it has to be modified in only one place.
Also allow the user to specify their own preferred command + options for
source packages in addition to compiled packages. Currently,
makepkg.conf(5) erroneously claims this is already possible.
|
|
Prior to commit aca153bfa6b1bcd828f0b35db453bb9fea6a08bf some .sh files
were not generated and simply included directly, and it was necessary to
explicitly iterate all ignored files to prevent git from ignoring the
directly-included files. However, now all .sh files are in fact
generated so it makes no sense to list each one separately in the
.gitignore file.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
For your convenience, makepkg now has 16 distinct ways to fail.
Also closes FS#54204.
Signed-off-by: Ivy Foster <iff@escondida.tk>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
