June 2018 - Pacman-dev - lists.archlinux.org

[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