aur sync -c $pkg fails to build in chroot

[brunnre8]

• Do you use the latest release of aurutils and its dependencies? If so, is the issue reproducible from the master branch?
  yes

$pacman -Q aurutils-git
aurutils-git 1.5.3.r573.g55f1c77-1

• Does the package conform to PKGBUILD(5) and the AUR package guidelines?
  yes, it fails as well for aurutils-git, which hopefully meets the guidelines 😉

• Does the package provide the correct metadata on the AUR RPC interface?
  yes, see above

• Does the package build with makepkg -s or extra-x86_64-build ?
  yes, even aur sync -u aurutils-git

• Is the problem reproducible, and not due to a misconfiguration of pacman, makepkg, sudoers, gpg or others?
  I am afraid I don't know, has nothing to do with sudoers / gpg. Though I am not sure about pacman / makepkg. Any pointers as to what to check will be appreciated

issue:

Running aur sync -cu aurutils-git fails with the error below, I expected a chroot to be generated. Is this a wrong assumption?

reto ~ bash -x aur sync -cu aurutils-git |& tee error.log
reto ~ cat error.log
+ readonly argv0=aur
+ argv0=aur
+ readonly lib_dir=/usr/lib/aurutils
+ lib_dir=/usr/lib/aurutils
+ shopt -s nullglob
+ [[ -z sync ]]
+ readonly PATH=/usr/lib/aurutils:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/reto/conda/bin:/home/reto/go/bin:/home/reto/Android/Sdk/platform-tools
+ PATH=/usr/lib/aurutils:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/reto/conda/bin:/home/reto/go/bin:/home/reto/Android/Sdk/platform-tools
+ type -P aur-sync
+ exec aur-sync -cu aurutils-git
  -> Using [custom] repository
  -> aurutils-git: (none) -> 1.5.3.r421.g44baaac-1
From https://aur.archlinux.org/aurutils-git
 = [up to date]      master     -> origin/master
==> ERROR: Please specify a working directory.

[AladW]

Thanks for the report. Could you git bisect the issue to a particular commit?

https://wiki.archlinux.org/index.php/Bisecting_bugs

[brunnre8]

Apparently that one, although I did have some issue with the bisecting due to various other commits failing for unrelated reasons, so this has to be taken with a grain of salt

cddd35886993e0786663fe50a41381d1e54a00f5 is the first bad commit
commit cddd35886993e0786663fe50a41381d1e54a00f5
Author: Alad Wenter <alad@archlinux.org>
Date:   Thu Apr 12 17:43:58 2018 +0200

    build-nspawn: now runs as regular user

    aur-build-nspawn is now called as a regular user as in the 1.5 branch.
    This removes the need to whitelist aur(1) with or without wildcards.

    install(1) is not required, as the container directory is already
    created by mkarchroot:

    https://git.archlinux.org/devtools.git/tree/mkarchroot.in#n64

:040000 040000 334b8911afe7df0b08ef7377148b9ac7dcfaec07 a2dacbad6b0a5661e5ad6096c7b4a82ebef9bdae M  lib
:040000 040000 75cf08cd856c528f2233fa701e27e641986c1937 8035d8845df062cdb05036964b62bf321085c753 M  man1

[AladW]

Yes, that's the commit I suspected. Will take a look.

[rafasc]

@AladW I've looked into this and seems that the removal of install(1) was incorrect.

mkarchroot will create {root,copy,$USER} in the "working_dir". But it needs to exist. If it doesn't it will straight up die.

https://git.archlinux.org/devtools.git/tree/mkarchroot.in#n49

working_dir="$(readlink -f "$1")"
shift 1

[[ -z $working_dir ]] && die 'Please specify a working directory.'

[AladW]

Thanks! That's unfortunate since there's no easy approach for sudoers then, unless you whitelisted /usr/bin/install (which most probably don't want to do).

I'd rather not go back to an aur(1) script running as root though. I wonder if there's some specific reason mkarchroot does not create this directory...

[rafasc]

I'd rather not go back to an aur(1) script running as root

I agree.

I wonder if there's some specific reason mkarchroot does not create this directory...

Not sure why too. It's even more peculiar if you consider they test for it again 13 lines below, before creating the directory.

https://git.archlinux.org/devtools.git/tree/mkarchroot.in#n62

[[ -e $working_dir ]] && die "Working directory '%s' already exists" "$working_dir"

mkdir -p "$working_dir"

Not sure if they're trying really hard to make sure the path up to the last component exists, and the last component doesn't, or if this is an unintentional leftover from the refactor done in 453558c4bb44b4bff43fcd22f96d4cfe1dbcf6f1 where the second test was introduced.

Should probably ask upstream for clarification.

[Earnestly]

It should really be using readlink -e instead of readlink -f.

[cjk]

Having the same problem, which means not being able to build | sync in a container (option -c) any more:

% aur build -d mypkgs -c -- llpp
==> ERROR: Please specify a working directory

[rafasc]

@cjk The problem comes from mkarchroot refusing to create the directory /var/lib/aurbuild/$(uname -m)/... if /var/lib/aurbuild/$(uname -m) is missing.

@AladW Can we make this directory as part of the install?¹ Because even if upstream changes this -f to -e as @Earnestly suggested, we will still have the same problem.

They would have to change to something like: readlink -m; mkdir -p

---

¹ Creating this directory at install time is not an option due to setarch support.

[AladW]

I don't have the means right now to fix this upstream, so I just added back install(1) with an appropriate comment. If the mkarchroot behavior changes, let me know and I'll revert it.

[maximbaz]

On a first glance, shouldn't it be [[ ! -d "$directory" ]] && sudo install ... to avoid unnecessary sudo calls? As far as I understood that folder needs to be created only once.