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