- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] repo-remove: Fix infinite loop when given a pkgname ending in '*'
by Rafael Ascensão 08 May '19

08 May '19

While this is most likely the result of user error, as repo-remove doesn't accept globs, using 'package*' as the pkgname will result in an endless loop of the following message being printed: -> Removing existing entry 'package**'... This happens because find_pkgentry() fails to account the case where globbing fails and the expression is taken literally. Fix that by checking the existence of the file before doing anything else. Signed-off-by: Rafael Ascensão <rafa.almas(a)gmail.com> --- scripts/repo-add.sh.in | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 57413df5..123bb796 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -120,10 +120,12 @@ find_pkgentry() { local pkgentry for pkgentry in "$tmpdir/db/$pkgname"*; do - name=${pkgentry##*/} - if [[ ${name%-*-*} = $pkgname ]]; then - echo $pkgentry - return 0 + if [[ -e $pkgentry ]]; then + name=${pkgentry##*/} + if [[ ${name%-*-*} = $pkgname ]]; then + echo $pkgentry + return 0 + fi fi done return 1 -- 2.21.0

5 7

[pacman-dev] [PATCH] makepkg: use more schema.sh to clean the environment of special variables
by Eli Schwartz 08 May '19

08 May '19

Fixes "arch" and "checkdepends" never having been unset, fixes b2sums (but not ${!b2sums_@}) being recently left out. The "build" function used to be unset as well, explicitly unset it as a function and do the same for other official functions as well. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/makepkg.sh.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 9708a65e..7f1a03df 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1214,9 +1214,9 @@ else fi fi -unset pkgname pkgbase pkgver pkgrel epoch pkgdesc url license groups provides -unset md5sums replaces depends conflicts backup source install changelog build -unset sha{1,224,256,384,512}sums makedepends optdepends options noextract validpgpkeys +unset "${pkgbuild_schema_strings[@]}" "${pkgbuild_schema_arrays[@]}" +unset "${known_hash_algos[@]/%/sums}" +unset -f pkgver prepare build check package "${!package_@}" unset "${!makedepends_@}" "${!depends_@}" "${!source_@}" "${!checkdepends_@}" unset "${!optdepends_@}" "${!conflicts_@}" "${!provides_@}" "${!replaces_@}" unset "${!md5sums_@}" "${!sha1sums_@}" "${!sha224sums_@}" "${!sha256sums_@}" -- 2.21.0

2 4

[pacman-dev] [PATCH] libmakepkg: fix missing dependency on error.sh
by Eli Schwartz 08 May '19

08 May '19

When the executable checking was refactored into libmakepkg, it carried with it, usage of $E_* error codes, which need to be declared from error.sh but are only available when the parent program already sources error.sh -- fix by adding the necessary dependency. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/libmakepkg/executable/vcs.sh.in | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/libmakepkg/executable/vcs.sh.in b/scripts/libmakepkg/executable/vcs.sh.in index 46631f39..399ae1d4 100644 --- a/scripts/libmakepkg/executable/vcs.sh.in +++ b/scripts/libmakepkg/executable/vcs.sh.in @@ -23,6 +23,7 @@ LIBMAKEPKG_EXECUTABLE_VCS_SH=1 LIBRARY=${LIBRARY:-'@libmakepkgdir@'} +source "$LIBRARY/util/error.sh" source "$LIBRARY/util/option.sh" executable_functions+=('executable_vcs') -- 2.21.0

2 2

[pacman-dev] [PATCH] meson: fix build of executables with nonstandard libarchive path
by Eli Schwartz 08 May '19

08 May '19

The libarchive header is used in alpm.h, and several binaries include this header. This is noticeably a problem when using e.g. the musl-gcc compiler which does not include /usr/include by default, and thus the build system reports: ...../lib/libalpm/alpm.h:35:10: fatal error: archive.h: No such file or directory More commonly, this will result in compiling against potentially the wrong headers, if the libarchive installation picked up by pkg-config is different from the one with headers in /usr/include, and /usr/include is in the -isystem path. Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- meson.build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meson.build b/meson.build index cbd4b5d0..91f05031 100644 --- a/meson.build +++ b/meson.build @@ -387,6 +387,7 @@ executable( pacman_conf_sources, include_directories : includes, link_with : [libalpm], + dependencies : [libarchive], install : true, ) @@ -395,6 +396,7 @@ executable( testpkg_sources, include_directories : includes, link_with : [libalpm], + dependencies : [libarchive], install : true, ) -- 2.21.0

2 1

[pacman-dev] [PATCH] makepkg: fix bash 5 compatibility when packaging symlinks to a directory
by Eli Schwartz 08 May '19

08 May '19

In commit b5191ea140386dd9b73e4509ffa9a6d347c1b5fa we moved to using shell globbing to print package files for a couple of reasons including reproducible packaging of .METADATA files. Unfortunately, this only works reliably when the glob pattern does not resolve to a symlinked directory due to a change in the bash 5.0 release. Note that the previous, desired behavior was rather to merely refuse to recurse into symlinked directories, but due to an unrelated issue, the symlink handling for globstar was reworked in a way that had this side effect. See https://lists.gnu.org/archive/html/bug-bash/2019-04/msg00015.html for discussion; this may be fixed at some point, but bash 5.0 is broken either way. The appropriate way of handling this seems to be to use **/* to match instead; this produces the same results on both bash 4 and bash 5, as the ** matches any leading directory component (or none), and the * matches any file, directory, or symlink to either one. Fixes FS#62278 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/makepkg.sh.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 4f096a36..fd06ce02 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -666,7 +666,8 @@ list_package_files() { ( export LC_COLLATE=C shopt -s dotglob globstar - printf '%s\0' ** + # bash 5.0 only works with combo directory + file globs + printf '%s\0' **/* ) } -- 2.21.0

2 1

[pacman-dev] [PATCH] Fix clang 8 string-plus-int warnings
by Rikard Falkeborn 08 May '19

08 May '19

Clang 8 warns that adding a string to an integer does not append to string. Indeed it doesn't, but that was not the intentetion. Use array indexing as suggested by the compiler to silence the warning. There should be no functional change. Example of warning message: alpm.c:71:54: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] sprintf(hookdir, "%s%s", myhandle->root, SYSHOOKDIR + 1); ~~~~~~~~~~~^~~ alpm.c:71:54: note: use array indexing to silence this warning sprintf(hookdir, "%s%s", myhandle->root, SYSHOOKDIR + 1); ^ & [ ] 1 warning generated. --- lib/libalpm/alpm.c | 2 +- src/pacman/conf.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c index 0f3db6f4..bd7a129a 100644 --- a/lib/libalpm/alpm.c +++ b/lib/libalpm/alpm.c @@ -68,7 +68,7 @@ alpm_handle_t SYMEXPORT *alpm_initialize(const char *root, const char *dbpath, * with a slash) correctly, we skip SYSHOOKDIR[0]; the regular +1 therefore * disappears from the allocation */ MALLOC(hookdir, strlen(myhandle->root) + strlen(SYSHOOKDIR), goto nomem); - sprintf(hookdir, "%s%s", myhandle->root, SYSHOOKDIR + 1); + sprintf(hookdir, "%s%s", myhandle->root, &SYSHOOKDIR[1]); myhandle->hookdirs = alpm_list_add(NULL, hookdir); /* set default database extension */ diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3b79fbc7..2d8518c4 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -975,11 +975,11 @@ int setdefaults(config_t *c) if(c->rootdir) { char path[PATH_MAX]; if(!c->dbpath) { - snprintf(path, PATH_MAX, "%s/%s", c->rootdir, DBPATH + 1); + snprintf(path, PATH_MAX, "%s/%s", c->rootdir, &DBPATH[1]); SETDEFAULT(c->dbpath, strdup(path)); } if(!c->logfile) { - snprintf(path, PATH_MAX, "%s/%s", c->rootdir, LOGFILE + 1); + snprintf(path, PATH_MAX, "%s/%s", c->rootdir, &LOGFILE[1]); SETDEFAULT(c->logfile, strdup(path)); } } else { -- 2.21.0

3 2

[pacman-dev] [PATCH] makepkg: correctly handle hg sources with updates on a non-default branch
by Eli Schwartz 08 May '19

08 May '19

The "tip" ref actually signifies the most recently updated branch. hg does not support a default branch named anything other than "default", except by creating a "@" bookmark. The correct way to explicitly update to the default clone ref, is therefore to use one of these, rather than "tip". Fixes FS#62092 Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/libmakepkg/source/hg.sh.in | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/libmakepkg/source/hg.sh.in b/scripts/libmakepkg/source/hg.sh.in index 4984883e..2fe32bab 100644 --- a/scripts/libmakepkg/source/hg.sh.in +++ b/scripts/libmakepkg/source/hg.sh.in @@ -79,7 +79,11 @@ extract_hg() { msg2 "$(gettext "Creating working copy of %s %s repo...")" "${repo}" "hg" pushd "$srcdir" &>/dev/null - local ref=tip + local ref=default + # Is the repository configured to checkout some ref other than 'default'? + if hg identify -r @ "$dir" >/dev/null 2>&1; then + ref=@ + fi if [[ -n $fragment ]]; then case ${fragment%%=*} in branch|revision|tag) -- 2.21.0

2 1

[pacman-dev] [PATCH] repo-add: should have option to prevent downgrading
by ekardnam 28 Apr '19

28 Apr '19

Hello, following this report #FS17752 (link at [0]) I made a patch to repo-add From 972a5e88df392042d60e5aea1e52e8c5dd113a69 Mon Sep 17 00:00:00 2001 From: ekardnam <lucabertozzi.pub(a)gmail.com> Date: Tue, 26 Mar 2019 21:28:39 +0000 Subject: [PATCH] Added --dont-downgrade flag to repo-add as stated in issue #17752 --- scripts/repo-add.sh.in | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 57413df5..f8748f08 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -42,6 +42,7 @@ REPO_DB_SUFFIX= LOCKFILE= CLEAN_LOCK=0 USE_COLOR='y' +DONT_DOWNGRADE=0 # Import libmakepkg source "$LIBRARY"/util/message.sh @@ -63,6 +64,7 @@ Multiple packages to add can be specified on the command line.\n")" printf -- "$(gettext "Options:\n")" printf -- "$(gettext " -n, --new only add packages that are not already in the database\n")" printf -- "$(gettext " -R, --remove remove old package file from disk after updating database\n")" + printf -- "$(gettext " --dont-downgrade do not add package to database if a newer version is already present\n")" elif [[ $cmd == "repo-remove" ]] ; then printf -- "$(gettext "Usage: repo-remove [options] <path-to-db> <packagename> ...\n")" printf -- "\n" @@ -248,9 +250,17 @@ db_write_entry() { return 0 fi else - if (( RMEXISTING )); then - pkgentry=$(find_pkgentry "$pkgname") - if [[ -n $pkgentry ]]; then + pkgentry=$(find_pkgentry "$pkgname") + if [[ -n $pkgentry ]]; then + + local version=$(sed -n '/^%VERSION%$/ {n;p;q}' "$pkgentry/desc") + if (( "$(vercmp $version $pkgver)" > "0" )); then + warning "$(gettext "A newer version for '%s' is already present in database")" "$pkgname" + if (( DONT_DOWNGRADE )); then + return 0 + fi + fi + if (( RMEXISTING )); then local oldfilename="$(sed -n '/^%FILENAME%$/ {n;p;q;}' "$pkgentry/desc")" local oldfile="$(dirname "$1")/$oldfilename" fi @@ -618,6 +628,9 @@ while (( $# )); do -v|--verify) VERIFY=1 ;; + --dont-downgrade) + DONT_DOWNGRADE=1 + ;; *) args+=("$1") ;; -- 2.19.2 ----------Links and stuff--------------- [0] https://bugs.archlinux.org/task/17752?project=3 ekardnam

4 6

[pacman-dev] [PATCH] libmakepkg: add routine for linting $SOURCE_DATE_EPOCH
by Eli Schwartz 16 Apr '19

16 Apr '19

This can only ever be an int, and the specification states that a malformed timestamp should be considered a fatal error. https://reproducible-builds.org/specs/source-date-epoch/ Signed-off-by: Eli Schwartz <eschwartz(a)archlinux.org> --- scripts/Makefile.am | 1 + .../lint_config/source_date_epoch.sh.in | 37 +++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100755 scripts/libmakepkg/lint_config/source_date_epoch.sh.in diff --git a/scripts/Makefile.am b/scripts/Makefile.am index 54a8d215..255aee2b 100644 --- a/scripts/Makefile.am +++ b/scripts/Makefile.am @@ -71,6 +71,7 @@ LIBMAKEPKG_IN = \ libmakepkg/integrity/verify_signature.sh \ libmakepkg/lint_config.sh \ libmakepkg/lint_config/paths.sh \ + libmakepkg/lint_config/source_date_epoch.sh \ libmakepkg/lint_config/variable.sh \ libmakepkg/lint_package.sh \ libmakepkg/lint_package/build_references.sh \ diff --git a/scripts/libmakepkg/lint_config/source_date_epoch.sh.in b/scripts/libmakepkg/lint_config/source_date_epoch.sh.in new file mode 100755 index 00000000..38fbfd77 --- /dev/null +++ b/scripts/libmakepkg/lint_config/source_date_epoch.sh.in @@ -0,0 +1,37 @@ +#!/bin/bash +# +# source_date_epoch.sh - Check that reproducible builds timestamp is valid +# +# Copyright (c) 2018 Pacman Development Team <pacman-dev(a)archlinux.org> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. +# + +[[ -n $LIBMAKEPKG_LINT_CONFIG_SOURCE_DATE_EPOCH_SH ]] && return +LIBMAKEPKG_LINT_CONFIG_SOURCE_DATE_EPOCH_SH=1 + +LIBRARY=${LIBRARY:-'@libmakepkgdir@'} + +source "$LIBRARY/util/message.sh" + +lint_config_functions+=('lint_source_date_epoch') + + +lint_source_date_epoch() { + if [[ $SOURCE_DATE_EPOCH = *[^[:digit:]]* ]]; then + error "$(gettext "%s contains invalid characters: %s")" \ + "\$SOURCE_DATE_EPOCH" "${SOURCE_DATE_EPOCH//[[:digit:]]}" + return 1 + fi +} -- 2.20.1

2 6

[pacman-dev] Running pacman with at(1).
by Ralph Corderoy 14 Apr '19

14 Apr '19

Hi, Due to bandwidth charges varying depending on the time of day, I've used at(1) in the past to `pacman -S' when I'm AFK. My recollection is something like this is sufficient; a `pacman -Syuw --noconfirm' will have run a little beforehand. sudo -i at '04:45 tomorrow' <<<'pacman -Sw foo...' But that didn't work last night; it gave similar output to running in a TTY with EOF on stdin. $ sudo -i pacman -Sw dbeaver </dev/null resolving dependencies... :: There are 3 providers available for java-runtime>=8: :: Repository extra 1) jre-openjdk 2) jre10-openjdk 3) jre8-openjdk Enter a number (default=1): Package (5) New Version Net Change Download Size extra/java-runtime-common 3-1 0.01 MiB extra/jre-openjdk 11.0.3.u4-1 0.52 MiB 0.17 MiB extra/jre-openjdk-headless 11.0.3.u4-1 156.57 MiB 29.18 MiB extra/libnet 1.1.6-3 0.34 MiB community/dbeaver 6.0.1-1 62.90 MiB 54.53 MiB Total Download Size: 83.88 MiB :: Proceed with download? [Y/n] $ Notice how the first prompt, that defaults to `1', seemed not to mind EOF and went with that default. The second prompt, to proceed with the download, also has a default, `Y', but EOF that time halts pacman. That seems inconsistent. Skipping the first prompt doesn't bless the second one with the first's behaviour of continuing. $ sudo -i pacman -Sw libnet </dev/null resolving dependencies... Package (1) New Version Net Change Download Size extra/libnet 1.1.6-3 0.34 MiB 0.09 MiB Total Download Size: 0.09 MiB :: Proceed with download? [Y/n] $ $ echo $? 1 $ Has this behaviour changed in the last few months? Or quite possibly my recollection is wrong. pacman(1) has --noconfirm Bypass any and all “Are you sure?” messages. It’s not a good idea to do this unless you want to run pacman from a script. Given the first prompt isn't a simple binary choice of confirmation, the man page could do with being a bit more explicit, perhaps The prompt is still displayed, but the default choice is always taken. -- Cheers, Ralph.

2 1