This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official devtools repository".
The branch, master has been updated
via 38c7a391b043547b946a99731a56a233458ba7a2 (commit)
via 75ad2aca572d36c4df1b07153e2403534fbd89ed (commit)
via aee72cae3231811058d6993d71f97e449e477d8f (commit)
via 5ab8f8430a2c865656cd800c03ac21cb17a86d3c (commit)
via c9e287e845973e4c04e21fc513caaea4907e604e (commit)
via 48b2f8dcc49d88e60bd9e4ee97c92fea8ac90721 (commit)
via 3b725b58434b92e93ff90164fae8d76c4761706a (commit)
from 7a3c5085017987b6ef934cf9d9b098b4994ba21a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 38c7a391b043547b946a99731a56a233458ba7a2
Author: Bartłomiej Piotrowski
Date: Sun Jan 21 14:18:43 2018 +0100
makechrootpkg: make sure that makepkg.conf is always parsed as text
commit 75ad2aca572d36c4df1b07153e2403534fbd89ed
Author: Luke Shumaker
Date: Mon Jan 15 17:57:00 2018 +0100
makechrootpkg: Adjust to work properly with `set -e`
This worked properly until eab5aba.
commit aee72cae3231811058d6993d71f97e449e477d8f
Author: Luke Shumaker
Date: Mon Jan 15 17:57:00 2018 +0100
lib/common.sh: Adjust to work properly with `set -u`
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.
commit 5ab8f8430a2c865656cd800c03ac21cb17a86d3c
Author: Luke Shumaker
Date: Mon Jan 15 17:57:00 2018 +0100
arch-nspawn: Remove pointless $(echo ...) subshell
commit c9e287e845973e4c04e21fc513caaea4907e604e
Author: Luke Shumaker
Date: Mon Jan 15 17:57:00 2018 +0100
arch-nspawn: make sure that makepkg.conf is always parsed as text
https://lists.parabola.nu/pipermail/dev/2017-June/005576.html
commit 48b2f8dcc49d88e60bd9e4ee97c92fea8ac90721
Author: Eli Schwartz
Date: Sun Sep 3 03:53:40 2017 -0400
makechrootpkg: Fix anti-pattern when checking for enabled features
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
commit 3b725b58434b92e93ff90164fae8d76c4761706a
Author: Eli Schwartz
Date: Sun Sep 3 03:53:39 2017 -0400
makechrootpkg: Fix unconditionally running namcap
Fixes regression in 2fd5931a8c67289a8a4acd327b3ce99a5d64c8c7
$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
-----------------------------------------------------------------------
Summary of changes:
arch-nspawn.in | 4 ++--
lib/common.sh | 4 +++-
makechrootpkg.in | 10 +++++-----
3 files changed, 10 insertions(+), 8 deletions(-)
hooks/post-receive
--
The official devtools repository