- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] libmakepkg: remove accidentally added file
by Allan McRae 21 Jun '18

21 Jun '18

A blank file slipped into libmakepkg in commit 2c94118d. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/libmakepkg/lint_pkgbuild/3 | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 scripts/libmakepkg/lint_pkgbuild/3 diff --git a/scripts/libmakepkg/lint_pkgbuild/3 b/scripts/libmakepkg/lint_pkgbuild/3 deleted file mode 100644 index e69de29b..00000000 -- 2.17.1

1 0

[pacman-dev] [PATCH] alpm-hooks.5: include more information on hook files
by Jouke Witteveen 20 Jun '18

20 Jun '18

--- This is a follow-up to my hook sorting patch. The information added is also available in pacman.conf(5), and in pacman(8), but this looks like a good place to repeat it. doc/alpm-hooks.5.asciidoc | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/doc/alpm-hooks.5.asciidoc b/doc/alpm-hooks.5.asciidoc index 1d19f96e..cf8d2710 100644 --- a/doc/alpm-hooks.5.asciidoc +++ b/doc/alpm-hooks.5.asciidoc @@ -30,9 +30,14 @@ DESCRIPTION libalpm provides the ability to specify hooks to run before or after transactions based on the packages and/or files being modified. Hooks consist of a single '[Action]' section describing the action to be run and one or more -'[Trigger]' section describing which transactions it should be run for. Hook -file names are required to have the suffix ".hook". Hooks are run in -alphabetical order of their file name. +'[Trigger]' section describing which transactions it should be run for. + +Hooks are read from files located in the system hook directory ++{datarootdir}/libalpm/hooks+, and additional custom directories. Additional +directories are specified linkman:pacman.conf[5]. The default +additional directory is +{sysconfdir}/pacman.d/hooks+. Hook file names are +required to have the suffix ".hook". Hooks are run in alphabetical order of +their file name, where the ordering ignores the suffix. TRIGGERS -------- -- 2.17.1

1 0

[pacman-dev] [PATCH 1/6] libmakepkg/util/option: Refactor checking to reduce code duplication
by Jan Alexander Steffens (heftig) 19 Jun '18

19 Jun '18

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. --- scripts/libmakepkg/util/option.sh.in | 85 +++++++++------------------- 1 file changed, 28 insertions(+), 57 deletions(-) diff --git a/scripts/libmakepkg/util/option.sh.in b/scripts/libmakepkg/util/option.sh.in index 46e0568d..3299df9c 100644 --- a/scripts/libmakepkg/util/option.sh.in +++ b/scripts/libmakepkg/util/option.sh.in @@ -48,95 +48,66 @@ in_opt_array() { } +## +# usage : check_opt_array( $option, $expected_val, $haystack ) +# return : 0 - matches expected +# 1 - does not match expected +# 127 - not found +## +check_opt_array() { + local option=$1 expected=$2; shift 2 + + in_opt_array "$option" "$@" + case $? in + 0) # assert enabled + [[ $expected = y ]] + return ;; + 1) # assert disabled + [[ $expected = n ]] + return ;; + esac + + # not found + return 127 +} + + ## # Checks to see if options are present in makepkg.conf or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_option( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_option() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # fall back to makepkg.conf options - in_opt_array "$1" ${OPTIONS[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${OPTIONS[@]}" "${options[@]}" } ## # Check if option is present in BUILDENV # # usage : check_buildenv( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildenv() { - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = "y" ]] - return ;; - 1) # assert disabled - [[ $2 = "n" ]] - return ;; - esac - - # not found - return 127 + check_opt_array "$@" "${BUILDENV[@]}" } + ## # Checks to see if options are present in BUILDENV or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_buildoption( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildoption() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${BUILDENV[@]}" "${options[@]}" } -- 2.17.1

1 5

[pacman-dev] [PATCH] libmakepkg/tidy: fix debug sources not being properly detected sometimes
by Eli Schwartz 19 Jun '18

19 Jun '18

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. This fixes debug package generation for many packages that use absolute paths in their build systems... like CMake. Reported-by: Jagannathan Tiruvallur Eachambadi <jagannathante(a)gmail.com> Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/libmakepkg/tidy/strip.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/libmakepkg/tidy/strip.sh.in b/scripts/libmakepkg/tidy/strip.sh.in index 36d1b89e..5937e13c 100644 --- a/scripts/libmakepkg/tidy/strip.sh.in +++ b/scripts/libmakepkg/tidy/strip.sh.in @@ -37,7 +37,7 @@ build_id() { source_files() { LANG=C readelf "$1" --debug-dump | \ - awk '/DW_AT_name +:/{name=$8}/DW_AT_comp_dir +:/{print $8 "/" name}' + awk '/DW_AT_name +:/{name=$8}/DW_AT_comp_dir +:/{{if (name !~ /^\//) {printf "%s/", $8}}{print name}}' } strip_file() { -- 2.17.1

1 1

[pacman-dev] [PATCH 01/10] libmakepkg/util/option: Refactor checking to reduce code duplication
by Jan Alexander Steffens (heftig) 19 Jun '18

19 Jun '18

Pull out the expected=y/n check into a separate function and make use of the fact we can just concatenate the fallback arrays to get the same result. --- scripts/libmakepkg/util/option.sh.in | 85 +++++++++------------------- 1 file changed, 28 insertions(+), 57 deletions(-) diff --git a/scripts/libmakepkg/util/option.sh.in b/scripts/libmakepkg/util/option.sh.in index 46e0568d..28357e27 100644 --- a/scripts/libmakepkg/util/option.sh.in +++ b/scripts/libmakepkg/util/option.sh.in @@ -48,95 +48,66 @@ in_opt_array() { } +## +# usage : check_opt_array( $option, $expected_val, $haystack ) +# return : 0 - matches expected +# 1 - does not match expected +# 127 - not found +## +check_opt_array() { + local option=$1 expected=$2; shift 2 + + in_opt_array "$option" "$@" + case $? in + 0) # assert enabled + [[ $expected = y ]] + return ;; + 1) # assert disabled + [[ $expected = n ]] + return ;; + esac + + # not found + return 127 +} + + ## # Checks to see if options are present in makepkg.conf or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_option( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_option() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # fall back to makepkg.conf options - in_opt_array "$1" ${OPTIONS[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${options[@]}" "${OPTIONS[@]}" } ## # Check if option is present in BUILDENV # # usage : check_buildenv( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildenv() { - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = "y" ]] - return ;; - 1) # assert disabled - [[ $2 = "n" ]] - return ;; - esac - - # not found - return 127 + check_opt_array "$@" "${BUILDENV[@]}" } + ## # Checks to see if options are present in BUILDENV or PKGBUILD; # PKGBUILD options always take precedence. # # usage : check_buildoption( $option, $expected_val ) # return : 0 - matches expected # 1 - does not match expected # 127 - not found ## check_buildoption() { - in_opt_array "$1" ${options[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - in_opt_array "$1" ${BUILDENV[@]} - case $? in - 0) # assert enabled - [[ $2 = y ]] - return ;; - 1) # assert disabled - [[ $2 = n ]] - return - esac - - # not found - return 127 + check_opt_array "$@" "${options[@]}" "${BUILDENV[@]}" } -- 2.17.0

4 17

[pacman-dev] [PATCH] libalpm/dload.c: add case for CURLE_COULDNT_RESOLVE_HOST
by Michael Straube 19 Jun '18

19 Jun '18

Add a case for curl error 'Could not resolve host'. An attempt to fix FS#48285. Signed-off-by: Michael Straube <straubem(a)gmx.de> --- lib/libalpm/dload.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index eeef32f5..7f34c89e 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -473,6 +473,13 @@ static int curl_download_internal(struct dload_payload *payload, payload->remote_name, hostname); } goto cleanup; + case CURLE_COULDNT_RESOLVE_HOST: + payload->unlink_on_fail = 1; + handle->pm_errno = ALPM_ERR_SERVER_BAD_URL; + _alpm_log(handle, ALPM_LOG_ERROR, + _("failed retrieving file '%s' from %s : %s\n"), + payload->remote_name, hostname, error_buffer); + goto cleanup; default: /* delete zero length downloads */ if(fstat(fileno(localf), &st) == 0 && st.st_size == 0) { -- 2.17.1

2 1

[pacman-dev] [PATCH] Revert "makepkg: use the `declare` builtin when backing up variables to eval"
by Allan McRae 19 Jun '18

19 Jun '18

This reverts commit 9e52a36794552b77ecf26f7f34b226d096978f1e. The change to use declare for the split package metadata backup/restore resulted in variables being declared at a local scope. When these variables were unset (mostly noticed with debug packaging) this left the variable at global scope defined. The decided fix for this requires the use of bash-4.2 features, which is greater than our current minimum version and so is not suitable for a maint release. Revert the change in the meantime. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 32423262..d35dd62d 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1125,22 +1125,34 @@ check_build_status() { backup_package_variables() { local var for var in ${splitpkg_overrides[@]}; do - declare -p $var 2>/dev/null || printf '%s\n' "unset $var" + local indirect="${var}_backup" + eval "${indirect}=(\"\${$var[@]}\")" + done +} + +restore_package_variables() { + local var + for var in ${splitpkg_overrides[@]}; do + local indirect="${var}_backup" + if [[ -n ${!indirect} ]]; then + eval "${var}=(\"\${$indirect[@]}\")" + else + unset ${var} + fi done } run_split_packaging() { local pkgname_backup=("${pkgname[@]}") - local restore_package_variables for pkgname in ${pkgname_backup[@]}; do pkgdir="$pkgdirbase/$pkgname" mkdir "$pkgdir" - restore_package_variables="$(backup_package_variables)" + backup_package_variables run_package $pkgname tidy_install lint_package || exit $E_PACKAGE_FAILED create_package - eval "$restore_package_variables" + restore_package_variables done pkgname=("${pkgname_backup[@]}") create_debug_package -- 2.17.1

1 0

[pacman-dev] [PATCH] PKGBUILD(5): Remove reference to ChangeLog prototype inclusion
by Allan McRae 19 Jun '18

19 Jun '18

We do not distribute a ChangeLog prototype, so should not reference it in the man page. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- doc/PKGBUILD.5.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc index c57038c2..f12effde 100644 --- a/doc/PKGBUILD.5.asciidoc +++ b/doc/PKGBUILD.5.asciidoc @@ -18,9 +18,9 @@ PKGBUILD is written, the actual package is built using makepkg and installed with pacman. NOTE: An example PKGBUILD, useful for reference, is located in '{pkgdatadir}' -along with other example files such as a ChangeLog and an install -script. You can copy the provided PKGBUILD.proto file to a new package build -directory and make customizations to suit your needs. +along with other example files such as an install script. You can copy the +provided PKGBUILD.proto file to a new package build directory and make +customizations to suit your needs. Options and Directives -- 2.17.1

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.1.0-19-g0d6e82d3
by Allan McRae 19 Jun '18

19 Jun '18

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 pacman repository". The branch, master has been updated via 0d6e82d3748653a2b61ea34b940011ef97350768 (commit) via d750c854bcfa2461742a4d5dff7b4747db5c1f53 (commit) via 72263e22bdf2f33b2038f902612ac6a98954d254 (commit) via a92a36070ad520afe45cb6dacf1de2f0caac612d (commit) via 5cf6f614eb418a9e89c0cbfa5fbfac0d502ff668 (commit) via 793202344b47914d06a2c48bacbb6b232f7c5387 (commit) via e6dbe82c0c52011b4abb46283ba606eb75577ce7 (commit) via 05a3641c76ba1c07dbec6fa1d9e9d3fcf6dec20c (commit) via ab1e92860bdc5388621e8314b8e1652590fa2b05 (commit) via b37a6063d0d37eb16465693439e3dfb92409e44a (commit) via f78914cc6e3d431ec585c29e469a91121d90a5cf (commit) via de8c5e78bbaec3aea16523d1a7c5cc6801154c80 (commit) via 737596f038590878d9ac73e6e8de01ad22b2b340 (commit) via 870d4c8fdd5e53c24c2a13cf1010b2536460fd8f (commit) via c37a06fe1d1fbd2be73adc725323e8a4665eeb09 (commit) via 9eb3695a3ff850b9dff66d667a4b27be1a233f42 (commit) via 3a66b93be00b7a6b01a295bc203f91e663a133db (commit) via 930d50194754e9c75bc0d6d7ccc41ae8f4b4e5c4 (commit) via 716d776936a7c0559ef09a3b456fa52d2339a4aa (commit) from be4c491ceb34f04c3352ddd1d3c4672560e7ea8c (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 0d6e82d3748653a2b61ea34b940011ef97350768 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Thu Jun 14 22:25:25 2018 -0400 makepkg: don't print per-pkgname debug packages 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(a)archlinux.org> commit d750c854bcfa2461742a4d5dff7b4747db5c1f53 Author: Allan McRae <allan(a)archlinux.org> Date: Mon Jun 18 16:50:58 2018 +1000 Fix signing of debug packages Commit 9c8d7a80 broke the signing of debug packages by merging code up but not changing the test condition. Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 72263e22bdf2f33b2038f902612ac6a98954d254 Author: Michael Straube <straubem(a)gmx.de> Date: Wed Jun 13 16:49:27 2018 +0200 libalpm/dload.c: fix filename in license header The filename in the license header did not match the actual filename as in the other files. Hopefully this is not too nit-picky. Signed-off-by: Michael Straube <straubem(a)gmx.de> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit a92a36070ad520afe45cb6dacf1de2f0caac612d Author: Dave Reisner <dreisner(a)archlinux.org> Date: Sat Jun 9 15:24:42 2018 -0400 makepkg: fix initialization when extracting arrays 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(a)archlinux.org> commit 5cf6f614eb418a9e89c0cbfa5fbfac0d502ff668 Author: morganamilo <morganamilo(a)gmail.com> Date: Fri Jun 8 01:40:01 2018 +0100 Add missing sha224 sums in man page and linting Signed-off-by: morganamilo <morganamilo(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 793202344b47914d06a2c48bacbb6b232f7c5387 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Mon Jun 4 09:31:19 2018 -0400 makepkg: fix erroneous $BUILDDIR when $startdir is not an absolute path When comparing the $BUILDDIR to the $startdir, we used string equality instead of testing whether they are the same location, and ended up appending $pkgbase even though there's no reason to use it here. In some cases, this could result in makepkg erroring when trying to create $srcdir/$pkgdir, if a file with the same name as the $pkgbase exists. This is expected behavior if a file "src" or "pkg" exists, but decidedly less so for $pkgbase. This could be fixed either by setting $startdir to an absolute path, or by ensuring the test checks this directly; I've chosen to do both, since the test should really be correctly checking the thing it actually cares about, but since we ensure absolute paths are used everywhere else, this might bite us elsewhere someday. It's also more consistent. Fixes FS#58865 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit e6dbe82c0c52011b4abb46283ba606eb75577ce7 Author: Allan McRae <allan(a)archlinux.org> Date: Mon Jun 4 22:44:01 2018 +1000 PKGBUILD.5: document restriction on pkgrel The format of pkgrel was much more retrictive than described in the man page. Update the documentation to reflect this. Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 05a3641c76ba1c07dbec6fa1d9e9d3fcf6dec20c Author: Jan Alexander Steffens (heftig) <jan.steffens(a)gmail.com> Date: Thu May 31 17:46:51 2018 +0200 makepkg: Don't use parameterless return It's especially dangerous in trap handlers since the return value of the function becomes the return value of the last command before the trap, not the last command in the current function. This applies to any function executed in a trap handler, nested functions included. In one case, install_packages failed (via return 14), which was inside a conditional that then ran exit 14, which triggered the EXIT handler, which called clean_up, which called remove_deps, which had !RMDEPS and thus returned. The return value of remove_deps became the return value of install_packages, triggering the ERR handler, which (due to another problem) was still the user function handler, which then printed a misleading error message and overrode the exit code with 4. Signed-off-by: Allan McRae <allan(a)archlinux.org> commit ab1e92860bdc5388621e8314b8e1652590fa2b05 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Sun Jun 3 01:31:17 2018 -0400 makepkg: fix the --nocolor option being broken when passed to pacman -U In commit 8ff03868a37b1f9c447784ae2fd639a49e426399 PACMAN_OPTS was turned into an array. Unfortunately, that array was generated by treating the "--color never" option as one string, instead of an array of two strings... Fixes FS#58820 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit b37a6063d0d37eb16465693439e3dfb92409e44a Author: Luke Shumaker <lukeshu(a)parabola.nu> Date: Sun Jun 3 16:01:32 2018 -0400 pacman.conf: Fixup the XferCommand example for curl 1. Without `-L`, curl doesn't follow redirects. This is different than both the default behavior of pacman, and from the wget example. So add `-L`. 2. It uses `-C -` to supposedly allow resuming partial downloads; but that doesn't work if we use `> %o` to direct the output to the file. Instead, use `-o %o` so that `-C -` actually works. Signed-off-by: Luke Shumaker <lukeshu(a)parabola.nu> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit f78914cc6e3d431ec585c29e469a91121d90a5cf Author: Jan Alexander Steffens (heftig) <jan.steffens(a)gmail.com> Date: Thu May 31 18:24:54 2018 +0200 makepkg: Clear ERR trap before trying to restore it $restoretrap is empty if the trap was not set. This caused the trap handler to remain and override later exit codes. Signed-off-by: Allan McRae <allan(a)archlinux.org> commit de8c5e78bbaec3aea16523d1a7c5cc6801154c80 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Thu May 31 20:31:23 2018 -0400 libmakepkg/lint_pkgbuild: squelch syntax error when a pkgname is empty 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(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 737596f038590878d9ac73e6e8de01ad22b2b340 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Wed May 30 22:50:25 2018 -0400 makepkg: do not chmod $BUILDDIR itself after checking for its existence In commit d8717a6a9666ec80c8645d190d6f9c7ab73084ac the write permission checks were refactored. Initially we intended to drop this chmod in the process, but due to some confusion about whether it was needed, I ended up submitting patches both to preserve and to remove it... but it's not needed after all. We do it on the individual $srcdir/$pkgdir, later on. Then, we used the wrong version, which causes unnecessary restrictions. See FS#58790 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 870d4c8fdd5e53c24c2a13cf1010b2536460fd8f Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Wed May 30 22:50:24 2018 -0400 libmakepkg/lint_pkgbuild: permit versioned optdepends 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(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit c37a06fe1d1fbd2be73adc725323e8a4665eeb09 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Wed May 30 22:50:23 2018 -0400 libmakepkg: when checking for write permissions, handle pre-existing dirs 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(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 9eb3695a3ff850b9dff66d667a4b27be1a233f42 Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Tue May 29 13:07:47 2018 -0400 makepkg: remove unused variable forgotten when moving to parseopts Reported-by: Rafael Ascensão <rafa.almas(a)gmail.com> Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 3a66b93be00b7a6b01a295bc203f91e663a133db Author: Eli Schwartz <eschwartz(a)archlinux.org> Date: Tue May 29 13:05:18 2018 -0400 makepkg: update help text to describe --packagelist's new behavior In commit d8591dd3418d55c5736022ef003891fc03b953e0 when teaching --packagelist to print the full filepath for built arches only, I forgot to update the helptext at the same time as I updated the manpage. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 930d50194754e9c75bc0d6d7ccc41ae8f4b4e5c4 Author: Allan McRae <allan(a)archlinux.org> Date: Wed May 30 08:45:12 2018 +1000 pacman-conf: fix detection of repo usage pacman-conf returned All for any repo Usage query because it was checking if any repo options were enabled rather than if all options were enabled. Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 716d776936a7c0559ef09a3b456fa52d2339a4aa Author: Allan McRae <allan(a)archlinux.org> Date: Mon May 28 13:47:36 2018 +1000 Apparently we live in the future! Signed-off-by: Allan McRae <allan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: doc/PKGBUILD.5.asciidoc | 13 ++++++----- doc/index.asciidoc | 2 +- etc/pacman.conf.in | 2 +- lib/libalpm/dload.c | 2 +- .../libmakepkg/integrity/generate_signature.sh.in | 2 +- scripts/libmakepkg/lint_pkgbuild/optdepends.sh.in | 18 ++++++++++----- scripts/libmakepkg/lint_pkgbuild/pkgname.sh.in | 3 +-- scripts/libmakepkg/lint_pkgbuild/variable.sh.in | 3 ++- scripts/libmakepkg/util/pkgbuild.sh.in | 13 +++++++---- scripts/libmakepkg/util/util.sh.in | 10 ++++----- scripts/makepkg.sh.in | 26 +++++++++++----------- src/pacman/pacman-conf.c | 4 ++-- 12 files changed, 57 insertions(+), 41 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH v2] makepkg: don't print per-pkgname debug packages
by Allan McRae 18 Jun '18

18 Jun '18

From: Eli Schwartz <eschwartz(a)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. --- This is a reduced patch of what was sent to the list earlier, now suitable for included in 5.1.1. scripts/libmakepkg/util/pkgbuild.sh.in | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in b/scripts/libmakepkg/util/pkgbuild.sh.in index 10d154d1..4b4b38e0 100644 --- a/scripts/libmakepkg/util/pkgbuild.sh.in +++ b/scripts/libmakepkg/util/pkgbuild.sh.in @@ -184,10 +184,11 @@ print_all_package_names() { for pkg in ${pkgname[@]}; do architecture=$(get_pkg_arch $pkg) printf "%s/%s-%s-%s%s\n" "$PKGDEST" "$pkg" "$version" "$architecture" "$PKGEXT" - if check_option "debug" "y" && check_option "strip" "y"; then - printf "%s/%s-%s-%s-%s%s\n" "$PKGDEST" "$pkg" "@DEBUGSUFFIX@" "$version" "$architecture" "$PKGEXT" - fi done + if check_option "debug" "y" && check_option "strip" "y"; then + architecture=$(get_pkg_arch) + printf "%s/%s-%s-%s-%s%s\n" "$PKGDEST" "$pkgbase" "@DEBUGSUFFIX@" "$version" "$architecture" "$PKGEXT" + fi } get_all_sources() {

1 0

[pacman-dev] [PATCH] Fix signing of debug packages
by Allan McRae 18 Jun '18

18 Jun '18

Commit 9c8d7a80 broke the signing of debug packages by merging code up but not changing the test condition. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Using this minimal fix for 5.1.1. Eli's patch refacotring this will be considered later. scripts/libmakepkg/integrity/generate_signature.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/libmakepkg/integrity/generate_signature.sh.in b/scripts/libmakepkg/integrity/generate_signature.sh.in index 442fe031..b53a90d0 100644 --- a/scripts/libmakepkg/integrity/generate_signature.sh.in +++ b/scripts/libmakepkg/integrity/generate_signature.sh.in @@ -63,7 +63,7 @@ create_package_signatures() { done # check if debug package needs a signature - if ! check_option "debug" "y" || ! check_option "strip" "y"; then + if check_option "debug" "y" && check_option "strip" "y"; then pkg=$pkgbase-@DEBUGSUFFIX@ pkgarch=$(get_pkg_arch) pkg_file="$PKGDEST/${pkg}-${fullver}-${pkgarch}${PKGEXT}" -- 2.17.1

2 1

[pacman-dev] [PATCH] libmakepkg/integrity: use more shared functions to generate signatures
by Eli Schwartz 18 Jun '18

18 Jun '18

The newly changed print_all_package_names function can iterate over the list of all package files that will be created; this avoids the need to independently recreate those filenames here. Additionally, since debug packages may not actually exist, check if the package file exists first. If the main package does not exist then makepkg will have aborted before now, so there is no need to special-case that here. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- .../integrity/generate_signature.sh.in | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/scripts/libmakepkg/integrity/generate_signature.sh.in b/scripts/libmakepkg/integrity/generate_signature.sh.in index 442fe031..3350ca50 100644 --- a/scripts/libmakepkg/integrity/generate_signature.sh.in +++ b/scripts/libmakepkg/integrity/generate_signature.sh.in @@ -50,25 +50,12 @@ create_package_signatures() { if [[ $SIGNPKG != 'y' ]]; then return 0 fi - local pkg pkgarch pkg_file - local fullver=$(get_full_version) msg "$(gettext "Signing package(s)...")" - for pkg in "${pkgname[@]}"; do - pkgarch=$(get_pkg_arch $pkg) - pkg_file="$PKGDEST/${pkg}-${fullver}-${pkgarch}${PKGEXT}" - - create_signature "$pkg_file" - done - - # check if debug package needs a signature - if ! check_option "debug" "y" || ! check_option "strip" "y"; then - pkg=$pkgbase-@DEBUGSUFFIX@ - pkgarch=$(get_pkg_arch) - pkg_file="$PKGDEST/${pkg}-${fullver}-${pkgarch}${PKGEXT}" + print_all_package_names | while read pkg_file; do if [[ -f $pkg_file ]]; then create_signature "$pkg_file" fi - fi + done } -- 2.17.1

2 3

[pacman-dev] [PATCH] makepkg: don't print per-pkgname debug packages
by Eli Schwartz 18 Jun '18

18 Jun '18

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: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/libmakepkg/util/pkgbuild.sh.in | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in b/scripts/libmakepkg/util/pkgbuild.sh.in index c2e2c536..44ba040a 100644 --- a/scripts/libmakepkg/util/pkgbuild.sh.in +++ b/scripts/libmakepkg/util/pkgbuild.sh.in @@ -189,11 +189,18 @@ print_all_package_names() { fi for a in "${architecture[@]}"; do printf "%s/%s-%s-%s%s\n" "$PKGDEST" "$pkg" "$version" "$a" "$PKGEXT" - if check_option "debug" "y" && check_option "strip" "y"; then - printf "%s/%s-%s-%s-%s%s\n" "$PKGDEST" "$pkg" "@DEBUGSUFFIX@" "$version" "$a" "$PKGEXT" - fi done done + if check_option "debug" "y" && check_option "strip" "y"; then + if (( IGNOREARCH )); then + get_pkgbuild_attribute '' 'arch' 1 architecture + else + architecture=$(get_pkg_arch) + fi + for a in "${architecture[@]}"; do + printf "%s/%s-%s-%s-%s%s\n" "$PKGDEST" "$pkgbase" "@DEBUGSUFFIX@" "$version" "$a" "$PKGEXT" + done + fi } get_all_sources() { -- 2.17.1

1 0

[pacman-dev] [PATCH] makepkg: install all dependencies simultanously, if possible when using rmdeps but not install, runtime dependencies do not need special handling for (non)removal, and can be installed in the same transaction. This allows pacman to intelligently resolve some things which would otherwise be conflicts.
by arch＠eckner.net 18 Jun '18

18 Jun '18

From: Erich Eckner <git(a)eckner.net> Signed-off-by: Erich Eckner <git(a)eckner.net> --- scripts/makepkg.sh.in | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index e9080a70..625b89a2 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1607,18 +1607,18 @@ else fi deperr=0 - msg "$(gettext "Checking runtime dependencies...")" - resolve_deps ${depends[@]} || deperr=1 - if (( RMDEPS && INSTALL )); then + msg "$(gettext "Checking runtime dependencies...")" + resolve_deps ${depends[@]} || deperr=1 + original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi msg "$(gettext "Checking buildtime dependencies...")" if (( CHECKFUNC )); then - resolve_deps "${makedepends[@]}" "${checkdepends[@]}" || deperr=1 + resolve_deps "${depends[@]}" "${makedepends[@]}" "${checkdepends[@]}" || deperr=1 else - resolve_deps "${makedepends[@]}" || deperr=1 + resolve_deps "${depends[@]}" "${makedepends[@]}" || deperr=1 fi if (( RMDEPS )); then -- 2.17.1

5 4

[pacman-dev] [PATCH] libalpm/dload.c: fix filename in license header
by Michael Straube 13 Jun '18

13 Jun '18

The filename in the license header did not match the actual filename as in the other files. Hopefully this is not too nit-picky. Signed-off-by: Michael Straube <straubem(a)gmx.de> --- lib/libalpm/dload.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 7f34c89e..cca39470 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -1,5 +1,5 @@ /* - * download.c + * dload.c * * Copyright (c) 2006-2018 Pacman Development Team <pacman-dev(a)archlinux.org> * Copyright (c) 2002-2006 by Judd Vinet <jvinet(a)zeroflux.org> -- 2.17.1

1 0

[pacman-dev] [PATCH] makepkg: optimize and fix BUILDINFO generation's use of awk
by Eli Schwartz 13 Jun '18

13 Jun '18

The biggest issue is directly supplying the data within the format string which can result in misinterpreting formatter sequences if a printed variable contains an "%" in it. This character is currently permitted in the pkgver field, though not in the pkgname. Also pacman/libalpm itself has much looser limitations and this can appear anywhere at all if a package was created by some other program. For the package "iambroke-1%s-1-any.pkg.tar.xz", installed in the build environment, the result is: -> Generating .BUILDINFO file... awk: cmd. line:3: (FILENAME=- FNR=1085) fatal: not enough arguments to satisfy format string `-1%s-1' ^ ran out for this one Followed by a .BUILDINFO which contains an LC_ALL=C sorted list of $pkgname-${epoch:+$epoch:}$pkgver-$pkgrel-$arch ending in: installed = iambroke Which is cut short, then fails to list the succeeding packages. The package itself successfully builds. It's also unnecessary to save the output of pacman -Qq in order to get the information for pacman -Qi, since the latter will, just like the former, return information for all installed packages if not given a package name(s). While I am at it, pipe this directly to awk rather than keeping a copy in an unnecessary local variable. This is slightly more efficient in addition to preventing the <<< herestring from re-interpreting the content of "$pkginfos" in ways that don't really matter for our usage. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/makepkg.sh.in | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index a5b0cbdf..987bb9f1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -699,13 +699,11 @@ write_buildinfo() { write_kv_pair "buildenv" "${BUILDENV[@]}" write_kv_pair "options" "${OPTIONS[@]}" - local pkglist=($(run_pacman -Qq)) - local pkginfos="$(LC_ALL=C run_pacman -Qi ${pkglist[@]})" - local pkginfos_parsed=($(awk -F': ' '\ - /^Name .*/ {printf $2} \ - /^Version .*/ {printf "-"$2} \ + local pkginfos_parsed=($(LC_ALL=C run_pacman -Qi | awk -F': ' '\ + /^Name .*/ {printf "%s", $2} \ + /^Version .*/ {printf "-%s", $2} \ /^Architecture .*/ {print "-"$2} \ - ' <<< "${pkginfos}")) + ')) write_kv_pair "installed" "${pkginfos_parsed[@]}" } -- 2.17.1

1 0

[pacman-dev] [PATCH] makepkg: when signing packages, report package filename on failure
by Eli Schwartz 12 Jun '18

12 Jun '18

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(a)archlinux.org> --- scripts/libmakepkg/integrity/generate_signature.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/libmakepkg/integrity/generate_signature.sh.in b/scripts/libmakepkg/integrity/generate_signature.sh.in index 261b18f7..1567ee89 100644 --- a/scripts/libmakepkg/integrity/generate_signature.sh.in +++ b/scripts/libmakepkg/integrity/generate_signature.sh.in @@ -40,7 +40,7 @@ create_signature() { if (( ! ret )); then msg2 "$(gettext "Created signature file %s.")" "${filename##*/}.sig" else - warning "$(gettext "Failed to sign package file.")" + warning "$(gettext "Failed to sign package file %s.")" "${filename##*/}" fi return $ret -- 2.17.1

1 0

[pacman-dev] [PATCH] scripts: pass on options such as set -x to child processes
by Eli Schwartz 12 Jun '18

12 Jun '18

When re-running makepkg for fakeroot, if `bash -x makepkg` was used this is lost. Fix by encoding the current set of options explicitly in the invocation, both for makepkg and for the wrapper used to test scripts inside the source tree. Also change to use ${BASH_SOURCE[0]} instead of $0 as the latter can be anything the parent process wants, while the former is explicitly set by bash itself to the filepath of the script. See http://mywiki.wooledge.org/BashFAQ/028 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/makepkg.sh.in | 2 +- scripts/wrapper.sh.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index efa21e7f..a5b0cbdf 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -181,7 +181,7 @@ clean_up() { enter_fakeroot() { msg "$(gettext "Entering %s environment...")" "fakeroot" - fakeroot -- $0 -F "${ARGLIST[@]}" || exit $? + fakeroot -- bash -$- "${BASH_SOURCE[0]}" -F "${ARGLIST[@]}" || exit $? } # Automatically update pkgver variable if a pkgver() function is provided diff --git a/scripts/wrapper.sh.in b/scripts/wrapper.sh.in index 94c7e0ed..f9480ea4 100644 --- a/scripts/wrapper.sh.in +++ b/scripts/wrapper.sh.in @@ -20,4 +20,4 @@ DIR="@PWD@" -LIBRARY="$DIR"/libmakepkg exec "$DIR"/.lib/@PROGNAME@ "$@" +LIBRARY="$DIR"/libmakepkg exec bash -$- "$DIR"/.lib/@PROGNAME@ "$@" -- 2.17.1

1 0

[pacman-dev] [PATCH] makepkg: fix initialization when extracting arrays
by Dave Reisner 09 Jun '18

09 Jun '18

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 --- scripts/libmakepkg/util/pkgbuild.sh.in | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in b/scripts/libmakepkg/util/pkgbuild.sh.in index 10d154d1..3f8669ab 100644 --- a/scripts/libmakepkg/util/pkgbuild.sh.in +++ b/scripts/libmakepkg/util/pkgbuild.sh.in @@ -106,7 +106,11 @@ get_pkgbuild_attribute() { local pkgname=$1 attrname=$2 isarray=$3 outputvar=$4 - printf -v "$outputvar" %s '' + if (( isarray )); then + eval "$outputvar=()" + else + printf -v "$outputvar" %s '' + fi if [[ $pkgname ]]; then extract_global_variable "$attrname" "$isarray" "$outputvar" -- 2.17.1

1 0

[pacman-dev] [PATCH] Add missing sha224 sums in man page and linting
by morganamilo 08 Jun '18

08 Jun '18

Signed-off-by: morganamilo <morganamilo(a)gmail.com> --- doc/PKGBUILD.5.asciidoc | 2 +- scripts/libmakepkg/lint_pkgbuild/variable.sh.in | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc index 9634bd15..f1897f86 100644 --- a/doc/PKGBUILD.5.asciidoc +++ b/doc/PKGBUILD.5.asciidoc @@ -152,7 +152,7 @@ contain whitespace characters. be skipped. To easily generate md5sums, run ``makepkg -g >> PKGBUILD''. If desired, move the md5sums line to an appropriate location. -*sha1sums, sha256sums, sha384sums, sha512sums (arrays)*:: +*sha1sums, sha224sums, sha256sums, sha384sums, sha512sums (arrays)*:: Alternative integrity checks that makepkg supports; these all behave similar to the md5sums option described above. To enable use and generation of these checksums, be sure to set up the `INTEGRITY_CHECK` option in diff --git a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in index 3266cb5e..00039bc5 100644 --- a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in @@ -34,7 +34,8 @@ lint_variable() { local array=(arch backup checkdepends groups license noextract options validpgpkeys) local arch_array=(conflicts depends makedepends md5sums optdepends provides - replaces sha1sums sha256sums sha384sums sha512sums source) + replaces sha1sums sha224sums sha256sums sha384sums sha512sums + source) local string=(changelog epoch install pkgdesc pkgrel pkgver url) local i a v pkg keys out bad ret=0 -- 2.17.1

1 0

Re: [pacman-dev] pacman-dev Digest, Vol 153, Issue 9
by pacman-dev 04 Jun '18

04 Jun '18

---- On Mon, 04 Jun 2018 14:03:41 -0700 <pacman-dev-request(a)archlinux.org> wrote ---- > Send pacman-dev mailing list submissions to > pacman-dev(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.archlinux.org/listinfo/pacman-dev > or, via email, send a message with subject or body 'help' to > pacman-dev-request(a)archlinux.org > > You can reach the person managing the list at > pacman-dev-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pacman-dev digest..." > > > Today's Topics: > > 1. [PATCH] PKGBUILD.5: document restriction on pkgrel (Allan McRae) > 2. Re: [PATCH] makepkg: Treat pkgrel more similarly to pkgver > (Allan McRae) > 3. [PATCH] makepkg: fix erroneous $BUILDDIR when $startdir is > not an absolute path (Eli Schwartz) > 4. pacman user+group support without mtree (pacman-dev) > 5. Re: pacman user+group support without mtree (Eli Schwartz) > 6. Re: pacman user+group support without mtree (Andrew Gregory) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jun 2018 22:50:02 +1000 > From: Allan McRae <allan(a)archlinux.org> > To: pacman-dev(a)archlinux.org > Subject: [pacman-dev] [PATCH] PKGBUILD.5: document restriction on > pkgrel > Message-ID: <20180604125002.2806-1-allan(a)archlinux.org> > > The format of pkgrel was much more retrictive than described in the > man page. Update the documentation to reflect this. > > Signed-off-by: Allan McRae <allan(a)archlinux.org> > --- > > Is this explanation clear? We also need to update the error message from > lint_pkgrel to be more accurate. > > doc/PKGBUILD.5.asciidoc | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc > index ac26f3fe..b7e07165 100644 > --- a/doc/PKGBUILD.5.asciidoc > +++ b/doc/PKGBUILD.5.asciidoc > @@ -56,11 +56,13 @@ new `pkgver`. This is most useful when used with sources from version control > systems (see below). > > *pkgrel*:: > - This is the release number specific to the Arch Linux release. This > + This is the release number specific to the distribution. This > allows package maintainers to make updates to the package's configure > flags, for example. This is typically set to '1' for each new upstream > software release and incremented for intermediate PKGBUILD updates. The > - variable is not allowed to contain hyphens. > + variable is a postive integer, with an optional subrelease level > + specified by adding another postive integer separated by a period > + (i.e. in the form x.y). > > *epoch*:: > Used to force the package to be seen as newer than any previous versions > -- > 2.17.0 > > > ------------------------------ > > Message: 2 > Date: Mon, 4 Jun 2018 22:52:57 +1000 > From: Allan McRae <allan(a)archlinux.org> > To: Discussion list for pacman development <pacman-dev(a)archlinux.org> > Subject: Re: [pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly > to pkgver > Message-ID: <06a21712-d07b-c992-1584-91684ae879d8(a)archlinux.org> > Content-Type: text/plain; charset=windows-1252 > > On 04/06/18 06:01, Luke Shumaker wrote: > > From: Luke Shumaker <lukeshu(a)parabola.nu> > > > > This is perfectly fine with libalpm; it was only makepkg that was more > > strict with pkgrel than pkgver. > > > > Further, the former error message about invalid pkgrel formats claimed that > > pkgrel was a "decimal", which would mean that `1.1 == 1.10`. This is not > > the case; alpm parses pkgrel as a version, not as a decimal. > > > > Signed-off-by: Luke Shumaker <lukeshu(a)parabola.nu> > > --- > > I am still very much against going beyond x.y for pkgrel. In fact, I > only begrudgingly accept the need for .y in there. > > A > > > ------------------------------ > > Message: 3 > Date: Mon, 4 Jun 2018 09:31:19 -0400 > From: Eli Schwartz <eschwartz(a)archlinux.org> > To: pacman-dev(a)archlinux.org > Subject: [pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when > $startdir is not an absolute path > Message-ID: <20180604133119.16049-1-eschwartz(a)archlinux.org> > > When comparing the $BUILDDIR to the $startdir, we used string equality > instead of testing whether they are the same location, and ended up > appending $pkgbase even though there's no reason to use it here. > > In some cases, this could result in makepkg erroring when trying to > create $srcdir/$pkgdir, if a file with the same name as the $pkgbase > exists. This is expected behavior if a file "src" or "pkg" exists, but > decidedly less so for $pkgbase. > > This could be fixed either by setting $startdir to an absolute path, or > by ensuring the test checks this directly; I've chosen to do both, since > the test should really be correctly checking the thing it actually cares > about, but since we ensure absolute paths are used everywhere else, this > might bite us elsewhere someday. It's also more consistent. > > Fixes FS#58865 > > Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> > --- > scripts/makepkg.sh.in | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in > index 2ed8561f..efa21e7f 100644 > --- a/scripts/makepkg.sh.in > +++ b/scripts/makepkg.sh.in > @@ -44,7 +44,7 @@ unset GREP_OPTIONS > declare -r makepkg_version='@PACKAGE_VERSION@' > declare -r confdir='@sysconfdir@' > declare -r BUILDSCRIPT='@BUILDSCRIPT@' > -declare -r startdir="$PWD" > +declare -r startdir="$(pwd -P)" > > LIBRARY=${LIBRARY:-'@libmakepkgdir@'} > > @@ -1458,7 +1458,7 @@ fi > > basever=$(get_full_version) > > -if [[ $BUILDDIR = "$startdir" ]]; then > +if [[ $BUILDDIR -ef "$startdir" ]]; then > srcdir="$BUILDDIR/src" > pkgdirbase="$BUILDDIR/pkg" > else > -- > 2.17.1 > > > ------------------------------ > > Message: 4 > Date: Mon, 04 Jun 2018 13:55:12 -0700 > From: pacman-dev <pacman-dev(a)dodtsair.com> > To: "pacman-dev" <pacman-dev(a)archlinux.org> > Subject: [pacman-dev] pacman user+group support without mtree > Message-ID: > <163cc95155a.c10d90fa104952.6720902778935437783(a)dodtsair.com> > Content-Type: text/plain; charset="UTF-8" > > > Hello Pacman Dev, > The basic question first, is there a way to create a tarball with .PKGINFO and use that tarball as a pacman package to install files with particular permissions without also adding a .MTREE file to that tarball? > > More context, currently we install files into our servers using a bash script. It pops open a tarball, keeping the users, groups, permissions, times for the files in the tarball, then it copies each file to the filesystem according to their location in the tarball. It works great for a cheap slightly better then POC solution. That tarball and a pacman pkg file are vary similar in that those are both tar files, with the files listed according to their desired location on the filesystem. So my idea was that it would be relatively easy for me to add the appropriate .PKGINFO into the tarball and switch from using my bash script to using pacman itself. This all worked great, except for users. In this case the file was created, in the right place, with the right permissions but the wrong user and group. > > $ tar -tvf vienna-os-scaffold-0.0.0-any.pkg.tar.xz | grep sbin/vienna > -r-x------ vienna/nogroup 533 2017-12-04 13:18 usr/local/sbin/vienna > ... > $ sudo pacman --noconfirm -U vienna-os-scaffold-0.0.0-any.pkg.tar.xz > warning: no 'XferCommand' configured > loading packages... > resolving dependencies... > looking for conflicting packages... > > Packages (1) vienna-os-scaffold-0.0.0-0 > > > :: Proceed with installation? [Y/n] > (1/1) checking package integrity [#####################################################################################################] 100% > (1/1) loading package files [#####################################################################################################] 100% > (1/1) checking for file conflicts [#####################################################################################################] 100% > (1/1) checking available disk space [#####################################################################################################] 100% > :: Processing package changes... > (1/1) installing vienna-os-scaffold > ... > $ ls -l /usr/local/sbin/vienna > -r-x------ 1 501 dialout 533 Dec 4 13:18 /usr/local/sbin/vienna > > As the above shell script snippets demonstrate, the file usr/local/sbin/vienna is owned by "vienna" in the tarball, and assigned to group "nogroup". It also is only readable and execute by the user. When deployed by pacman it retains the permission and is installed at /usr/local/sbin/vienna. Which is correct, but it is owned by dialout and 553? This is not correct. If I want the file to be installed with user=vienna and group=nogroup, do I need to create a .mtree file and add that to the package as well or is there some other way I can get pacman to look at the user and group of the file inside the tarball? > > Michael Power > > > ------------------------------ > > Message: 5 > Date: Mon, 4 Jun 2018 17:01:22 -0400 > From: Eli Schwartz <eschwartz(a)archlinux.org> > To: pacman-dev(a)archlinux.org > Subject: Re: [pacman-dev] pacman user+group support without mtree > Message-ID: <427232e1-ae1f-fafd-7e82-6c34fa47968a(a)archlinux.org> > Content-Type: text/plain; charset="utf-8" > > On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote: > > > > Hello Pacman Dev, The basic question first, is there a way to create > > a tarball with .PKGINFO and use that tarball as a pacman package to > > install files with particular permissions without also adding a > > .MTREE file to that tarball? > > > > More context, currently we install files into our servers using a > > bash script. It pops open a tarball, keeping the users, groups, > > permissions, times for the files in the tarball, then it copies each > > file to the filesystem according to their location in the tarball. > > It works great for a cheap slightly better then POC solution. That > > tarball and a pacman pkg file are vary similar in that those are both > > tar files, with the files listed according to their desired location > > on the filesystem. So my idea was that it would be relatively easy > > for me to add the appropriate .PKGINFO into the tarball and switch > > from using my bash script to using pacman itself. This all worked > > great, except for users. In this case the file was created, in the > > right place, with the right permissions but the wrong user and group. > > I'd suggest you have two choices to proceed from here: > - use makepkg to repackage your tarball > - generate the .MTREE which pacman expects > > The .MTREE is simple to make, this is where makepkg generates it: > https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.1.0#n7… > > As you can see, it's really just bsdtar --format=mtree with a couple > other options. > > -- > Eli Schwartz > Bug Wrangler and Trusted User > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: OpenPGP digital signature > URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20180604/fb33f…> > > ------------------------------ > > Message: 6 > Date: Mon, 4 Jun 2018 17:03:28 -0400 > From: Andrew Gregory <andrew.gregory.8(a)gmail.com> > To: Discussion list for pacman development <pacman-dev(a)archlinux.org> > Subject: Re: [pacman-dev] pacman user+group support without mtree > Message-ID: <20180604210327.GA604(a)b42-desktop.localdomain> > Content-Type: text/plain; charset=us-ascii > > On 06/04/18 at 05:01pm, Eli Schwartz wrote: > > On 06/04/2018 04:55 PM, pacman-dev via pacman-dev wrote: > > > > > > Hello Pacman Dev, The basic question first, is there a way to create > > > a tarball with .PKGINFO and use that tarball as a pacman package to > > > install files with particular permissions without also adding a > > > .MTREE file to that tarball? > > > > > > More context, currently we install files into our servers using a > > > bash script. It pops open a tarball, keeping the users, groups, > > > permissions, times for the files in the tarball, then it copies each > > > file to the filesystem according to their location in the tarball. > > > It works great for a cheap slightly better then POC solution. That > > > tarball and a pacman pkg file are vary similar in that those are both > > > tar files, with the files listed according to their desired location > > > on the filesystem. So my idea was that it would be relatively easy > > > for me to add the appropriate .PKGINFO into the tarball and switch > > > from using my bash script to using pacman itself. This all worked > > > great, except for users. In this case the file was created, in the > > > right place, with the right permissions but the wrong user and group. > > > > I'd suggest you have two choices to proceed from here: > > - use makepkg to repackage your tarball > > - generate the .MTREE which pacman expects > > > > The .MTREE is simple to make, this is where makepkg generates it: > > https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.1.0#n7… > > > > As you can see, it's really just bsdtar --format=mtree with a couple > > other options. > > pacman extracts the file with whatever uid and gid it has in the > tarball. The mtree file is completely irrelevant. I see, in particular you are saying that pacman uses the uid not the user name. Hence I should be using the --numeric-owner flag on tar when inspecting the package: $ tar --numeric-owner -tvf vienna-os-scaffold-0.0.0-any.pkg.tar.xz | grep sbin/vienna -r-x------ 501/20 533 2017-12-04 13:18 usr/local/sbin/vienna Since the package is built with uid 501 which does not exist, and gid 20 which belongs to dialout then pacman installs the files with the corresponding ids, the names are ignored. $ grep dialout /etc/group dialout:x:20: $ grep 501 /etc/passwd $ $ ls -l /usr/local/sbin/vienna -r-x------ 1 501 dialout 533 Dec 4 13:18 /usr/local/sbin/vienna Solution for me is to build the tarball using uid and gid. Michael Power

1 0

[pacman-dev] pacman user+group support without mtree
by pacman-dev 04 Jun '18

04 Jun '18

Hello Pacman Dev, The basic question first, is there a way to create a tarball with .PKGINFO and use that tarball as a pacman package to install files with particular permissions without also adding a .MTREE file to that tarball? More context, currently we install files into our servers using a bash script. It pops open a tarball, keeping the users, groups, permissions, times for the files in the tarball, then it copies each file to the filesystem according to their location in the tarball. It works great for a cheap slightly better then POC solution. That tarball and a pacman pkg file are vary similar in that those are both tar files, with the files listed according to their desired location on the filesystem. So my idea was that it would be relatively easy for me to add the appropriate .PKGINFO into the tarball and switch from using my bash script to using pacman itself. This all worked great, except for users. In this case the file was created, in the right place, with the right permissions but the wrong user and group. $ tar -tvf vienna-os-scaffold-0.0.0-any.pkg.tar.xz | grep sbin/vienna -r-x------ vienna/nogroup 533 2017-12-04 13:18 usr/local/sbin/vienna ... $ sudo pacman --noconfirm -U vienna-os-scaffold-0.0.0-any.pkg.tar.xz warning: no 'XferCommand' configured loading packages... resolving dependencies... looking for conflicting packages... Packages (1) vienna-os-scaffold-0.0.0-0 :: Proceed with installation? [Y/n] (1/1) checking package integrity [#####################################################################################################] 100% (1/1) loading package files [#####################################################################################################] 100% (1/1) checking for file conflicts [#####################################################################################################] 100% (1/1) checking available disk space [#####################################################################################################] 100% :: Processing package changes... (1/1) installing vienna-os-scaffold ... $ ls -l /usr/local/sbin/vienna -r-x------ 1 501 dialout 533 Dec 4 13:18 /usr/local/sbin/vienna As the above shell script snippets demonstrate, the file usr/local/sbin/vienna is owned by "vienna" in the tarball, and assigned to group "nogroup". It also is only readable and execute by the user. When deployed by pacman it retains the permission and is installed at /usr/local/sbin/vienna. Which is correct, but it is owned by dialout and 553? This is not correct. If I want the file to be installed with user=vienna and group=nogroup, do I need to create a .mtree file and add that to the package as well or is there some other way I can get pacman to look at the user and group of the file inside the tarball? Michael Power

3 2

[pacman-dev] [PATCH] makepkg: fix erroneous $BUILDDIR when $startdir is not an absolute path
by Eli Schwartz 04 Jun '18

04 Jun '18

When comparing the $BUILDDIR to the $startdir, we used string equality instead of testing whether they are the same location, and ended up appending $pkgbase even though there's no reason to use it here. In some cases, this could result in makepkg erroring when trying to create $srcdir/$pkgdir, if a file with the same name as the $pkgbase exists. This is expected behavior if a file "src" or "pkg" exists, but decidedly less so for $pkgbase. This could be fixed either by setting $startdir to an absolute path, or by ensuring the test checks this directly; I've chosen to do both, since the test should really be correctly checking the thing it actually cares about, but since we ensure absolute paths are used everywhere else, this might bite us elsewhere someday. It's also more consistent. Fixes FS#58865 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/makepkg.sh.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 2ed8561f..efa21e7f 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -44,7 +44,7 @@ unset GREP_OPTIONS declare -r makepkg_version='@PACKAGE_VERSION@' declare -r confdir='@sysconfdir@' declare -r BUILDSCRIPT='@BUILDSCRIPT@' -declare -r startdir="$PWD" +declare -r startdir="$(pwd -P)" LIBRARY=${LIBRARY:-'@libmakepkgdir@'} @@ -1458,7 +1458,7 @@ fi basever=$(get_full_version) -if [[ $BUILDDIR = "$startdir" ]]; then +if [[ $BUILDDIR -ef "$startdir" ]]; then srcdir="$BUILDDIR/src" pkgdirbase="$BUILDDIR/pkg" else -- 2.17.1

1 0

[pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly to pkgver
by Luke Shumaker 04 Jun '18

04 Jun '18

From: Luke Shumaker <lukeshu(a)parabola.nu> This is perfectly fine with libalpm; it was only makepkg that was more strict with pkgrel than pkgver. Further, the former error message about invalid pkgrel formats claimed that pkgrel was a "decimal", which would mean that `1.1 == 1.10`. This is not the case; alpm parses pkgrel as a version, not as a decimal. Signed-off-by: Luke Shumaker <lukeshu(a)parabola.nu> --- This is a patch from Parabola, that we've been maintaining and applying to our pacman package for a while. I originally wrote it against version 4.1.2, and have submitted upstream before: https://lists.archlinux.org/pipermail/pacman-dev/2014-August/019340.html Dan McGee and Allan McRae weren't fans of it then. https://lists.archlinux.org/pipermail/pacman-dev/2014-August/019340.html https://lists.archlinux.org/pipermail/pacman-dev/2014-September/019351.html Allan was "of the opinion that the pkgrel should be a positive integer and nothing else." Dan thought it shouldn't be complicated, as "we're not trying to copy or match an upstream value." Well, in Arch, you're not trying to copy an upstream value, but in Parabola and in Arch Linux 32, we are. Currently in Arch Linux 32 they take advantage of makepkg's current behavior: when modifying a PKGBUILD from Arch, they append ".$N to the pkgrel from Arch, and don't modify the existing number, so that it is easy to tell that "foo-X-Y.Z" is based on "foo-X-Y" from Arch (and Z is the Arch 32-specific pkgrel); they are matching an upstream value. Prior to applying this patch, Parabola did the same thing. Since applying this patch, we've transitioned to "foo-X-Y.parabolaZ". This is even more relevant now, since we also import packages from Arch 32, which may already have a ".Z". When building foo-static, we might use "foo-static-X-Y.staticZ" to clearly indicate that it is based on the PKGBUILD for "foo-X-Y". Allan had said that he would consider "Inclusion of a 'dist' keyword in PKGBUILDs. If present, this gets added onto the end of the pkgrel." I think that's introducing new weird semantics where we don't need any. Normal versioning semantics do fine; pkgrel is a version number of the packaging metadata, and "Y.distZ" says "version Y, and then Z patches", same as any other patchlevel; similar to ".gitZ" in a pkgver. doc/PKGBUILD.5.asciidoc | 3 ++- scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in | 4 ++-- test/util/vercmptest.sh | 23 ++++++++++++++++++- 3 files changed, 26 insertions(+), 4 deletions(-) diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc index 9634bd15..a75b40fe 100644 --- a/doc/PKGBUILD.5.asciidoc +++ b/doc/PKGBUILD.5.asciidoc @@ -60,7 +60,8 @@ systems (see below). allows package maintainers to make updates to the package's configure flags, for example. This is typically set to '1' for each new upstream software release and incremented for intermediate PKGBUILD updates. The - variable is not allowed to contain hyphens. + variable is not allowed to contain colons, forward slashes, hyphens or + whitespace. *epoch*:: Used to force the package to be seen as newer than any previous versions diff --git a/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in b/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in index f294a3bf..07292613 100644 --- a/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in @@ -35,8 +35,8 @@ lint_pkgrel() { return 1 fi - if [[ $pkgrel != +([0-9])?(.+([0-9])) ]]; then - error "$(gettext "%s must be a decimal, not %s.")" "pkgrel" "$pkgrel" + if [[ $pkgrel = *[[:space:]/:-]* ]]; then + error "$(gettext "%s is not allowed to contain colons, forward slashes, hyphens or whitespace.")" "pkgrel" "$pkgrel" return 1 fi } diff --git a/test/util/vercmptest.sh b/test/util/vercmptest.sh index 1541e7ae..f41a0d1e 100755 --- a/test/util/vercmptest.sh +++ b/test/util/vercmptest.sh @@ -39,7 +39,7 @@ tap_runtest() { tap_is_str "$($bin "$ver2" "$ver1")" "$exp" "$ver2 $ver1" } -tap_plan 92 +tap_plan 124 # all similar length, no pkgrel tap_runtest 1.5.0 1.5.0 0 @@ -113,4 +113,25 @@ tap_runtest 1:1.0 1.0 1 tap_runtest 1:1.0 1.1 1 tap_runtest 1:1.1 1.1 1 +# complex pkgrel values +tap_runtest 1-1.5.0 1-1.5.0 0 +tap_runtest 1-1.5.1 1-1.5.0 1 +tap_runtest 1-1.5.1 1-1.5 1 +tap_runtest 1-1.5b 1-1.5 -1 +tap_runtest 1-1.5b 1-1.5.1 -1 +# based on "from the manpage" +tap_runtest 1-1.0a 1-1.0alpha -1 +tap_runtest 1-1.0alpha 1-1.0b -1 +tap_runtest 1-1.0b 1-1.0beta -1 +tap_runtest 1-1.0beta 1-1.0rc -1 +tap_runtest 1-1.0rc 1-1.0 -1 +# based on "going crazy? alpha-dotted versions" +tap_runtest 1-1.5.a 1-1.5 1 +tap_runtest 1-1.5.b 1-1.5.a 1 +tap_runtest 1-1.5.1 1-1.5.b 1 +# based on Parabola usage +tap_runtest 1-1 1-2.par1 -1 +tap_runtest 1-2 1-2.par1 -1 +tap_runtest 1-3 1-2.par1 1 + tap_finish -- 2.17.1

2 1

[pacman-dev] [PATCH] PKGBUILD.5: document restriction on pkgrel
by Allan McRae 04 Jun '18

04 Jun '18

The format of pkgrel was much more retrictive than described in the man page. Update the documentation to reflect this. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Is this explanation clear? We also need to update the error message from lint_pkgrel to be more accurate. doc/PKGBUILD.5.asciidoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc index ac26f3fe..b7e07165 100644 --- a/doc/PKGBUILD.5.asciidoc +++ b/doc/PKGBUILD.5.asciidoc @@ -56,11 +56,13 @@ new `pkgver`. This is most useful when used with sources from version control systems (see below). *pkgrel*:: - This is the release number specific to the Arch Linux release. This + This is the release number specific to the distribution. This allows package maintainers to make updates to the package's configure flags, for example. This is typically set to '1' for each new upstream software release and incremented for intermediate PKGBUILD updates. The - variable is not allowed to contain hyphens. + variable is a postive integer, with an optional subrelease level + specified by adding another postive integer separated by a period + (i.e. in the form x.y). *epoch*:: Used to force the package to be seen as newer than any previous versions -- 2.17.0

1 0