Support for working with `set -u` was broken by 94160d6. Egg on my
face; I'm the one who wants `set -u` support, and I'm the author of
that commit!
libmakepkg does not work with `set -u`; but mostly because of the include
guards! So we just need to temporarily disable `set -u` (nounset) while
loading libmakepkg. Instead of introducing a new variable, just store the
initial nounset status in _INCLUDE_COMMON_SH; rather than a useless
fixed-string "true".
While we're at it, disable POSIX-mode (just in case we're running as "sh"
instead of "bash"), since libmakepkg uses bash-isms that won't parse in
POSIX mode.
Don't use error-prone logic e.g.
foo=true; if $foo ...
This completely fails to act as expected when the variable is unset
because of unrelated bugs.
While this merely causes the default behavior to be "false" rather than
"true" in such cases, it is better to fail to enable explicitly
requested behavior (which will be noticed by the user) than to simply
upgrade to this behavior for free (which may not seem to have any
obvious cause).
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Fixes regression in 2fd5931a8c
$run_namcap will always be set to ""
`if $not_a_var; then ...; fi` is always truthful when $not_a_var is
unset or equal to "" and the `then` clause will always be run.
I'm not sure why global state variables need to be cloned locally for
their sole explicit purpose.
But for now this patch implements the minimum necessary work to properly
pass the "do I want namcap" variable into prepare_chroot() according to
the current logic flow.
Note that I have still not thorougly tested makechrootpkg.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Recent development versions of makepkg support reproducible builds
through the environment variable SOURCE_DATE_EPOCH. Pass this variable
through makechrootpkg to makepkg when available.
Also initialize SOURCE_DATE_EPOCH whenever running archbuild to enforce
reproducible builds for repository packages.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
A couple of the comments noting which globals are used by functions are
outdated/wrong.
- download_sources() : Remove USER from the list. It was always wrong.
Originally, it should have been SUDO_USER (not USER), but I should have
removed it entirely in 4f23609.
- move_products() : Add SRCPKGDEST to the list. Though the commit adding
the comment was only recently upstreamed (as 2fd5931), it originated in
2013 in a commit that has since been rebased many times. Anyway, in
this rebasing, it missed move_products() starting to pay attention to
SRCPKGDEST in fd1be1b (since nothing made git think there was a
"conflict").
The reason it wasn't moved before was just to keep the diffs
(with --ignore-all-space) smaller, to make merging and rebasing work
easier. Moving code around in a file tends to make that difficult.
But, readability wise, it belongs in main().
nspawn does not give us a controlling terminal, hence we ignore
interrupts. Apparently this was lost in systemd at some point.
Hack around this by reopening the console to make it the controlling
terminal.
Coredumps from build chroots are not generally useful. Prevent
them from being generated.
Avoids a lot of annoyance from the GCC testsuite spawning lots of
systemd-coredump processes.
Just set the soft limit so the user can still raise it in the PKGBUILD
if they insist.
systemd-nspawn use a default environ PATH value of:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Since filesystem 2017.08, this is no more overrided by /etc/profile
to the Arch default:
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
Commit 58968cf fixed symlinks for package products in $startdir in
light of the simplified chroot setup. However, a similar change needs
to be made for source-package products. This was an easy omission to
make because makechrootpkg does not produce source-pakcages by
default.
- Use `read -r` instead of other forms of read or looping
- Use arrays instead of strings with whitespaces.
- In one instance, use ${var%%.*} instead of $(echo $var|cut -f. -d1)
The bug isn't currently triggered, but I accidentally did trigger when I
was trying to modify the command a bit. I figure a "caution" sign would be
helpful to any future developers.
The default m4 quote characters: `QUOTE' are troublesome, because ` is
fairly likely to pop up in a shell script (if not for a subshell, because
it is a useful character in comments and user-facing messages).
So, this changes it to [[[QUOTE]]], as it is unlikely to see three braces
together like that, let alone in unbalanced sets.
What this is really doing is fixing a conflict that I had incorrectly
resolved when rebasing what became 2fd5931 onto cda9cf4. Of course,
because of dynamic scoping, everything worked out, and everything worked as
intended.
Before cda9cf4, it was appropriate for download_sources to take src_owner
as an argument, but after cda9cf4, it is now appropriate to take
makepkg_user as an argument. However, it still takes src_owner as an
argument, but pays 0 attention to it; instead looking at makepkg_user which
it happily inherited because of dynamic scoping.
So change it to take makepkg_user as the argument.
The `-xdev` flag to `find` makes it not recurse over subvolumes; so it only
supports recursion with depth=1. Fix this by having the function
recursively call itself.
This is inspired by the thought that went in to the delete_chroot
is_subvolume commit.
sync_chroot($chrootdir, $copydir) copies `$chrootdir/root` to `$copydir`.
That seems a little silly; why do we care about "$chrootdir"? Have it just
be sync_chroot(source, destination) like every other sync/copy command.
Where this becomes tricky is check to decide if we are going to use btrfs
subvolumes or not. We don't care if "$source/.." is on btrfs; the root
could be a directly-mounted subvolume, but and the destination could be
another subvolume of the same btrfs mounted somewhere else.
The things we do care about are:
- The source is a btrfs subvolume (so that we can snapshot it)
- The source is on the same filesystem as the directory that the copy will
be created in.
- If the destination exists:
* that it is not a mountpoint (so that we can delete and recreate it)
* that it is a btrfs subvolume (so that we can quickly delete it)
On the last point, it isn't necessary for creating the new snapshot, just
for quick deletion. That can be a separate check, where we use regular
`rm` for deleting the existing copy, but use subvolume snapshots for
creating the new one.
Also, shorten the "Synchronizing" message to only include the full path
to the copy if it was specified.
The capslocked variable names in the Usage comment were references to
things in Parabola's tools, that didn't make much sense here out of
context.
First of all, it ran `is_btrfs "$chrootdir"` to decide if it was on
btrfs, but $chrootdir wasn't defined locally; it just happens to work
because $chrootdir was defined in main(). (I noticed this because in
Parabola, it is called differently, so $chrootdir was empty).
So I was tempted to just change it to `is_btrfs "$copydir"`, but if
$copydir is just a regular directory on a btrfs filesystem, then it
It would leave much of $copydir intact. What we really care about is
if $copydir is a btrfs subvolume; which we can check by combining the
is_btrfs check with inspecting the inum of the directory.
I put this combined check in lib/archroot.sh:is_subvolume.
https://lists.archlinux.org/pipermail/arch-projects/2013-September/003901.html
This means wrapping variable initialization in init_variables(), and the
main program routine in main().
I did NOT put `shopt -s nullglob` in to a function.
It make make sense to move init_variables() down into the main()
function, instead of having it as a separate function up top (if this
done, then the `-g` flag passed to `declare` in init_variables() can
be dropped). However, in interest of keeping the `diff -w` small, and
merges/rebases simpler, this isn't done here.
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.
Bartłomiej Piotrowski
Luke Shumaker
Eli Schwartz
Evangelos Foutras
Jan Alexander Steffens (heftig)
Sébastien Luttringer
Martchus
Laurent Carlier via arch-projects
Bartłomiej Piotrowski