- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] makepkg: set default value for PACKAGER
by Allan McRae 06 Jul '17

06 Jul '17

In write_pkginfo, we checked if $PACKAGER was undefined, and gave a default value if not. Just do this upfront to simplify this function. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 90f52abe..3c29c2d8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -622,12 +622,6 @@ write_kv_pair() { } write_pkginfo() { - if [[ -n $PACKAGER ]]; then - local packager="$PACKAGER" - else - local packager="Unknown Packager" - fi - local size="$(@DUPATH@ @DUFLAGS@)" size="$(( ${size%%[^0-9]*} * 1024 ))" @@ -651,7 +645,7 @@ write_pkginfo() { write_kv_pair "pkgdesc" "$spd" write_kv_pair "url" "$url" write_kv_pair "builddate" "$SOURCE_DATE_EPOCH" - write_kv_pair "packager" "$packager" + write_kv_pair "packager" "$PACKAGER" write_kv_pair "size" "$size" write_kv_pair "arch" "$pkgarch" @@ -1430,6 +1424,7 @@ PKGEXT=${_PKGEXT:-$PKGEXT} SRCEXT=${_SRCEXT:-$SRCEXT} GPGKEY=${_GPGKEY:-$GPGKEY} PACKAGER=${_PACKAGER:-$PACKAGER} +PACKAGER=${PACKAGER:-"Unknown Packager"} #default if undefined CARCH=${_CARCH:-$CARCH} if (( ! INFAKEROOT )); then -- 2.13.2

1 0

[pacman-dev] [PATCH] makepkg: always write pkgbase
by Allan McRae 06 Jul '17

06 Jul '17

There is little savings in only writing pkgbase when different to pkgname, and it makes determining the pkgbase by parsing .PKGINFO slightly easier. Lets just write it... Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index f9872355..90f52abe 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -638,9 +638,7 @@ write_pkginfo() { printf "# using %s\n" "$(fakeroot -v)" write_kv_pair "pkgname" "$pkgname" - if (( SPLITPKG )) || [[ "$pkgbase" != "$pkgname" ]]; then - write_kv_pair "pkgbase" "$pkgbase" - fi + write_kv_pair "pkgbase" "$pkgbase" local fullver=$(get_full_version) write_kv_pair "pkgver" "$fullver" -- 2.13.2

1 0

[pacman-dev] [PATCH] makepkg: do not write basever
by Allan McRae 06 Jul '17

06 Jul '17

Since 8a02abcf19, this attribute will never exist. Remove check to write it. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 3 --- 1 file changed, 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 1f1217f4..f9872355 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -644,9 +644,6 @@ write_pkginfo() { local fullver=$(get_full_version) write_kv_pair "pkgver" "$fullver" - if [[ "$fullver" != "$basever" ]]; then - write_kv_pair "basever" "$basever" - fi # TODO: all fields should have this treatment local spd="${pkgdesc//+([[:space:]])/ }" -- 2.13.2

1 0

[pacman-dev] [PATCH] libmakepkg: Fix improperly spelled local variable declaration
by Eli Schwartz 06 Jul '17

06 Jul '17

Signed-off-by: Eli Schwartz <eschwartz93(a)gmail.com> --- scripts/libmakepkg/integrity/verify_signature.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/libmakepkg/integrity/verify_signature.sh.in b/scripts/libmakepkg/integrity/verify_signature.sh.in index 5468f977..24519dbe 100644 --- a/scripts/libmakepkg/integrity/verify_signature.sh.in +++ b/scripts/libmakepkg/integrity/verify_signature.sh.in @@ -33,7 +33,7 @@ check_pgpsigs() { msg "$(gettext "Verifying source file signatures with %s...")" "gpg" local netfile proto pubkey success status fingerprint trusted - local warning=0 + local warnings=0 local errors=0 local statusfile=$(mktemp) local all_sources -- 2.13.2

1 0

[pacman-dev] [PATCH 1/2] libmakepkg: fix unsanitized source filenames
by Eli Schwartz 04 Jul '17

04 Jul '17

There were a couple places where filenames beginning with "-" were not properly guarded against by passing them after "--". Some PKGBUILD authors are crazy, but we still take those into account. Signed-off-by: Eli Schwartz <eschwartz93(a)gmail.com> --- scripts/libmakepkg/source/file.sh.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/libmakepkg/source/file.sh.in b/scripts/libmakepkg/source/file.sh.in index 1d85ea9b..41a5fb5c 100644 --- a/scripts/libmakepkg/source/file.sh.in +++ b/scripts/libmakepkg/source/file.sh.in @@ -96,7 +96,7 @@ extract_file() { fi # do not rely on extension for file type - local file_type=$(file -bizL "$file") + local file_type=$(file -bizL -- "$file") local ext=${file##*.} local cmd='' case "$file_type" in @@ -132,7 +132,7 @@ extract_file() { $cmd -xf "$file" || ret=$? else rm -f -- "${file%.*}" - $cmd -dcf "$file" > "${file%.*}" || ret=$? + $cmd -dcf -- "$file" > "${file%.*}" || ret=$? fi if (( ret )); then error "$(gettext "Failed to extract %s")" "$file" -- 2.13.2

1 1

Re: [pacman-dev] Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution
by Thomas Karlsson 21 Jun '17

21 Jun '17

Hello! I have several packages that install files that need to be owned by specific users on the target system. To achieve that I'm using the install command with the -o <username> and -g <group name> flags in the package() function. I'm not using a install script with a post_install() function. Example of the relevant part of the package function package() { install -m 600 -o username -g groupname the_file "$pkgdir"/some/path/to/the_file } The package is built on a build server and then installed on a number of targets. This has worked fine up until I upgraded to 5.0.2 After upgrading pacman to 5.0.2 the file does not get the correct owner on the target system any more. It gets own by the user that has the UID that the user has on the build server which is not the same UID as the user has on the target. To clarify. In my setup the UID of the user is different on the build server compared to the UID of the target system. Before this did not matter. The file got the correct ownership anyway. After 5.0.2 the file gets owned by whatever user account that has the UID and GID that the user has on the build server no matter what UID and GID the user has on the target system. As far as I can tell this is probably the commit that changed the behavior https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769b5400… Temporarily I have changed my PKGBUILD file to specify UID and GID that the target system has instead of the username and groupname on the install command but this seems fragile as it now requires that the UID/GID is the same on all target systems. Both existing and future. Is this an unintended side effect of the commit referenced above, or is this the expected behavior? Best regards, Thomas Karlsson

3 3

[pacman-dev] Correct alpm version to bind to?
by Colin Woodbury 13 Jun '17

13 Jun '17

Hi all, I'm the Aura dev. I'm writing alpm bindings for it, and I got a fair distance through before I realized that my up-to-date paper copies and the version of `alpm.h` actually bundled with pacman on my machine are quite different. The local one (/usr/include/alpm.h) is dated 2016 and has types / function signatures that vary a fair amount from what's currently on master, although they both report their versions to be 10.0.1. Is the most recent alpm supposed to be bundled with pacman? What incarnation of alpm does our installed pacman (5.0.1-5 as of this writing) bind to itself? Which version should be considered the "ground truth" for people writing bindings? Thanks, Colin

2 1

Re: [pacman-dev] [PATCH 1/1] alpm: use flock() for db lock
by Allan McRae 06 Jun '17

06 Jun '17

On 07/06/17 07:56, Christian Hesse wrote: > Allan McRae <allan(a)archlinux.org> on Wed, 2017/06/07 07:37: >> On 07/06/17 07:26, Christian Hesse wrote: >>> From: Christian Hesse <mail(a)eworm.de> >>> >>> We used to check for file existens, but that suffers from stale lock >>> files caused by unexpected events like crash, shutdown, etc. >>> >>> Instead use flock() to lock the file. It does not matter whether or >>> not the file exists but whether an exclusive lock can be obtained. >>> >>> Also remove the hint about removing the file from pacman. >> >> This does not work with NFS filesystems. > > Uh, did not know NFS has issues here. However, this is from NFS FAQ [0]: > >> The NFS client in 2.6.12 provides support for flock()/BSD locks on NFS files >> by emulating the BSD-style locks in terms of POSIX byte range locks. Other >> NFS clients that use the same emulation mechanism, or that use fcntl()/POSIX >> locks, will then see the same locks that the Linux NFS client sees. > > Given the fact that linux 2.6.12 has been released nearly twelve years ago... > We still do not want to use this? > > Does any other locking mechanism has a chance to be accepted? > > [0] http://nfs.sourceforge.net/#faq_d10 > Bringing back on list. We has issues with NFS/OSX last time this was run (need to look up last time this was discussed). I think out support for OSX is dead, so we could ignore that... I would not mind flock being used to lock individual files, but leaving an overall lock file during a transaction is useful. A

2 1

[pacman-dev] [PATCH 1/1] alpm: use flock() for db lock
by Christian Hesse 06 Jun '17

06 Jun '17

From: Christian Hesse <mail(a)eworm.de> We used to check for file existens, but that suffers from stale lock files caused by unexpected events like crash, shutdown, etc. Instead use flock() to lock the file. It does not matter whether or not the file exists but whether an exclusive lock can be obtained. Also remove the hint about removing the file from pacman. Signed-off-by: Christian Hesse <mail(a)eworm.de> --- lib/libalpm/handle.c | 17 +++++++++++++++-- src/pacman/util.c | 5 ----- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c index b6b27881..bb5cc907 100644 --- a/lib/libalpm/handle.c +++ b/lib/libalpm/handle.c @@ -24,6 +24,7 @@ #include <stdlib.h> #include <string.h> #include <limits.h> +#include <sys/file.h> #include <sys/types.h> #include <syslog.h> #include <sys/stat.h> @@ -120,10 +121,20 @@ int _alpm_handle_lock(alpm_handle_t *handle) FREE(dir); do { - handle->lockfd = open(handle->lockfile, O_WRONLY | O_CREAT | O_EXCL | O_CLOEXEC, 0000); + handle->lockfd = open(handle->lockfile, O_WRONLY | O_CREAT | O_CLOEXEC, 0000); } while(handle->lockfd == -1 && errno == EINTR); - return (handle->lockfd >= 0 ? 0 : -1); + if (handle->lockfd == -1) + return -1; + + /* try to get an exclusive lock */ + if (flock(handle->lockfd, LOCK_EX | LOCK_NB) == -1) { + close(handle->lockfd); + handle->lockfd = -1; + return -1; + } + + return 0; } /** Remove the database lock file @@ -137,6 +148,8 @@ int SYMEXPORT alpm_unlock(alpm_handle_t *handle) ASSERT(handle->lockfile != NULL, return 0); ASSERT(handle->lockfd >= 0, return 0); + flock(handle->lockfd, LOCK_UN); + close(handle->lockfd); handle->lockfd = -1; diff --git a/src/pacman/util.c b/src/pacman/util.c index ae8a74d3..c3f9d3ba 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -81,13 +81,8 @@ void trans_init_error(void) pm_printf(ALPM_LOG_ERROR, _("failed to init transaction (%s)\n"), alpm_strerror(err)); if(err == ALPM_ERR_HANDLE_LOCK) { - const char *lockfile = alpm_option_get_lockfile(config->handle); pm_printf(ALPM_LOG_ERROR, _("could not lock database: %s\n"), strerror(errno)); - if(access(lockfile, F_OK) == 0) { - fprintf(stderr, _(" if you're sure a package manager is not already\n" - " running, you can remove %s\n"), lockfile); - } } } -- 2.13.1

2 2

[pacman-dev] [PATCH 1/1] fix typo in libalpm comment
by Christian Hesse 06 Jun '17

06 Jun '17

From: Christian Hesse <mail(a)eworm.de> contatenate -> concatenate Signed-off-by: Christian Hesse <mail(a)eworm.de> --- lib/libalpm/alpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c index d3f951d5..28685fef 100644 --- a/lib/libalpm/alpm.c +++ b/lib/libalpm/alpm.c @@ -64,7 +64,7 @@ alpm_handle_t SYMEXPORT *alpm_initialize(const char *root, const char *dbpath, goto cleanup; } - /* to contatenate myhandle->root (ends with a slash) with SYSHOOKDIR (starts + /* to concatenate myhandle->root (ends with a slash) with SYSHOOKDIR (starts * 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); -- 2.13.1

1 0