Age | Commit message (Collapse) | Author |
|
A previous iteration of this change (libretools commit d7dcce53396d)
simply inserted `env -i` to clear the environment.
However, that lead to it ignoring proxy settings, which some users had
problems with:
https://labs.parabola.nu/issues/487:
> To fix other bugs, the pacstrap environment is blank, which also
> means that the proxy settings are blank.
So (in libretools commit d17d1d82349f), I changed it to use `declare
-x` to inspect the environment, and create a version of it only
consisting of variables ending with "_proxy" (case-insensitive).
I honestly don't remember what "other bugs" prompted me to clear the
environment in the first place.
|
|
This allows us to run an ARM chroot on an x86 box; as the binfmt
runner will set the architecture for us, and the x86
`/usr/bin/setarch` program won't know about the ARM architecture
string.
|
|
This allows us to copy in files like `qemu-arm-static`, which is
necessary for running an ARM chroot on an x86 box.
|
|
This is similar to common C #ifdef guards.
I was tempted to wrap the entire thing in the if/fi (rather than use
'return' to bail early. However, that means it won't execute anything
until after it reaches 'fi'. And if `shopt -s extglob` isn't executed
before parsing, then it will syntax-error on the extended globs. One
solution would have been to move `shopt -s extglob` up above the
include-guard. But the committed solution is all-around simpler.
|
|
for now)
|
|
|
|
Motivation:
tmpfiles.d(5) has directives to create btrfs subvolumes. This means
that systemd-tmpfiles (which may be called by an ALPM hook) might
create subvolumes. For instance, systemd's systemd-nspawn.conf
creates a subvolume at `/var/lib/machines/`.
This causes a problem when we go to delete the chroot. The command
`btrfs subvolume delete` won't recursively delete subvolumes; if a
child subvolume was created, it will fail with the fairly unhelpful
error message "directory not empty".
Solution:
Because the subvolume that gets mounted isn't necessarily the
toplevel subvolume, and `btrfs subvolume list` gives us paths
relative to the toplevel; we need to figure out how our path relates
to the toplevel. Figure out the mountpoint (which turns out to be
slightly tricky; see below), and call `btrfs subvolume list -a` on
it to get the list of subvolumes that are visible to us (and quite
possibly some that aren't; the logic for determining which ones it
shows is... absurd). This gives us a list of subvolumes with
numeric IDs, and paths relative to the toplevel (actually it gives
us more than that, and we use a hopefully-correct `sed` expression
to trim it down) So then we look at that list of pairs and find the
one that matches the ID of the subvolume we're trying to delete
(which is easy to get with `btrfs subvolume show`); once we've found
the path of our subvolume, we can use that to filter and trim the
complete list of paths. From there the remainder of the solution is
obvious.
Now, back to "figure out the mountpoint"; the normal `stat -c %m`
doesn't work. It gives the mounted path of the subvolume closest to
the path we give it, not the actual mountpoint. Now, it turns out
that `df` can figure out the correct mountpoint (though I haven't
investigated how it knows when stat doesn't; but I suspect it parses
`/proc/mounts`). So we are reduced to parsing `df`'s output.
Now, back to "hopefully-correct `sed` expression"; the output of
`btrfs subvolume list -a` is a space-separated sequence of
"key value key value...". Unfortunately both keys and values can
contain space, and there's no escaping or indication of when this
happens. With how we choose to parse it, a path containing a space
is truncated at the first space. This means that at least the
prefix is correct; if a path gets mangled, it just means that the
deletion fails. As "path" is (currently) the last key, it seems
tempting to allow it to simply run until the end of the line.
However, this creates the possibility of a path containing " path ",
which would cause the *prefix* to be trimmed, which means our
failure case is now unpredictable, and potentially harmful. While
we pretty much trust the user, that's still scary.
|
|
|
|
embedding.
|
|
It was displaing the value of the `makepkg_args` variable, which may
have already been changed by the argument parsing by the time it gets
to `-h`. Now there is a separate `default_makepkg_args` variable.
|
|
This involves extending the signature of lib/common.sh's `stat_busy()`,
`lock()`, and `slock()`. The `mesg=$1; shift` in stat_busy even suggests
that this is what was originally intended from it.
|
|
It was confusing Emacs and screwing up the syntax highlighting and
auto-indentation for the rest of the file.
|
|
|
|
|
|
|
|
Allow for locks to be inherited. Inheriting the lock is something that
mkarchroot could do previously, but has since lost the ability to do. This
allows for the programs to be more compos-able.
Do this by instead of unconditionally opening $file on $fd, first check if
$file is already open on $fd; and go ahead use it if it is.
The naive way of doing this would be to `$(readlink /dev/fd/$fd)` and
compare that to `$file`. However, if `$file` is itself a symlink; or there
is a symlink somewhere in the path to `$file`, then this could easily fail.
Instead, check `[[ "/dev/fd/$fd" -ef "$file" ]]`. Even though the Bash
documentation (`help test`) says that `-ef` checks for if the two files are
hard links to eachother, because it uses stat(3) (which resolves symlinks)
to do this check, it also works with the /dev/fd/ soft links.
|
|
`lock_close FD` is easier to remember than 'exec FD>&-`; and is especially
easier if FD is a variable (though that isn't actually taken advantage of
here).
This uses Bash 4.1+ `exec {var}>&-`, rather than the clunkier
`eval exec "$var>&-"` that was necessary in older versions of Bash.
Thanks to Dave Reisner for pointing this new bit of syntax out to me
the last time I submitted this (back in 2014, 4.1 had just come out).
|
|
The gnustep-base package ships a profile.d script that adds
"$HOME/GNUstep/Tools" to the PATH, which breaks when the user changes
and causes meson to exit with a "permission denied" error.
|
|
Make use of load_vars returning 1 when the file is missing. Avoids
introducing another variable.
|
|
Implemented the same way as in makepkg.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
|
|
|
|
|
|
Avoids having to specify them in dependency order.
|
|
Copy both UID and primary GID of the invoker to the builduser. Mount
srcdest and startdir read-write.
v2: Fixed GnuPG keyring owner and moved running namcap from a heredoc
to a function.
|
|
|
|
|
|
|
|
|
|
This makes it a lot easier to swap out the host that actually serves the repos in the future.
|
|
|
|
|
|
Having it set to nologin breaks a couple of tests in Git and Python.
|
|
This way the HOME dir is writable and no ugly hacks are required
in the PKGBUILD if $HOME is accessed (f.e. maven, gradle and also
some python tests etc.)
|
|
|
|
It is passed down to the container when stdin/stdout is not a tty; this
is the case when archbuild's output is redirected to a pipe or file.
|
|
|
|
|
|
|
|
|
|
This is needed in order to use GPG's auto-key-retrieve keyserver option,
otherwise the keyring will get copied to the chroot before the required
keys are retrieved during 'makepkg --verifysource'.
|
|
Pacman cannot handle armored signatures, so force a generation of a
binary one using the --no-armor flag.
|
|
|
|
Chances are that pubring.kbx has been created by gpgsm but pubring.gpg
is still around with valid data. We do not know what file contains what
we need, so just copy both.
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
|
|
|
|
|
|
|
|
It's an xmas miracle!
|
|
Needed for makepkg 4.2
|
|
bsdtar doesn't consider it an error when your --include doesn't match
anything in the archive, so we're forced to dump stderr to /dev/null
here.
Fixes: https://bugs.archlinux.org/task/42551
|
|
|