aurutils - helper tools for the aur

Alad · 2019-03-02 21:04:56

There's some degree of freedom here, e.g. if you want to build packages outside of your local repo, you can keep PKGDEST unset. Conversely, if you don't want to use aur-build all the time, you can set PKGDEST to where the local repo is, and use a tool like repoctl to automatically update the database.

SRCDEST is technically a "neater" solution since it keeps all downloaded sources in one place. In practice, it causes issues since packages (incorrectly) may have source archives of the same name.

Whether you set CacheDir also depends, benefits/downsides are described in man aur (for aurutils 2.3.1). In particular, wrong use of pacman or paccache may remove the local repo whole-sale. I use it mostly because I'm too lazy to bump pkgver on packages in my local repo.

Last edited by Alad (2019-03-02 21:06:14)

zf · 2019-03-04 03:44:36

After editing a PKGBUILD and then `aur sync -c <package>`, I get an error "skipping built package (use -f to overwrite)" (this is expected because I still have the package in cache. So I then "aur sync -cf <package>" to force it and when I go to edit the PKGBUILD, it has my saved changes.

Shouldn't I be getting a new copy downloaded with the -f option? That seems to make the most sense. I needed to remove the build files and do another "aur sync -cf <pacakge>" to get the untouched PKGBUILD from the AUR.

With regards to the CacheDir workaround, does that mean the bind mount alternative also mentioned in the man is a strictly better solution or does the suffer the same or other caveats?

What is your stance on an "aur remove"? Seems like it would make sense as "aur sync" does a "repo-add" but there's no counterpart for a repo-remove.

Would it make sense to add the same -R option in "aur build" to "aur sync"? Not sure if I'm doing it right but I'm just simply using "aur sync" for now and keeping things simple for both downloading and building, but the lack of "aur build -R" behavior means I have to do it manually after an "aur sync".

Last edited by zf (2019-03-04 03:51:49)

Alad · 2019-03-04 12:04:24

zf wrote:

After editing a PKGBUILD and then `aur sync -c <package>`, I get an error "skipping built package (use -f to overwrite)" (this is expected because I still have the package in cache. So I then "aur sync -cf <package>" to force it and when I go to edit the PKGBUILD, it has my saved changes.
Shouldn't I be getting a new copy downloaded with the -f option? That seems to make the most sense. I needed to remove the build files and do another "aur sync -cf <pacakge>" to get the untouched PKGBUILD from the AUR.

"skipping built package" sounds like the package was in the repo directory, but not added to the repo database; I guess this is what you mean by "I still have the package in cache".

aur-sync is supposed to undo any changes to a target package (reset to the AUR revision), whether you've specified -f or not. This assumes the PKGBUILD in question is in AURDEST or ~/.cache/aurutils/sync by default. Only when the package is not a target (e.g. when appended to --ignore, or matches a version check) are no changes undone in AURDEST.

If any of this goes wrong I'll need a more detailed description, including a step-by-step list I can reproduce. Ensure you use the latest aurutils version in the process.

With regards to the CacheDir workaround, does that mean the bind mount alternative also mentioned in the man is a strictly better solution or does the suffer the same or other caveats?

The only caveat here is that you might mistype a pacman command (-Scc instead of -Sc). Then again, you might also mistype "rm -r /usr/home/foo/" and remove /usr, so I don't consider it a big issue.

The only difference with a bind mount is that you can make it read-only, such that pacman/paccache command fails entirely, unless you specifically point it to the original repo directory. This makes CleanMethod less useful, though you keep the other benefits of using a CacheDir.

What is your stance on an "aur remove"? Seems like it would make sense as "aur sync" does a "repo-add" but there's no counterpart for a repo-remove.

You can use "repoctl remove", or add your own custom command. See: https://github.com/AladW/aurutils/pull/540

Would it make sense to add the same -R option in "aur build" to "aur sync"? Not sure if I'm doing it right but I'm just simply using "aur sync" for now and keeping things simple for both downloading and building, but the lack of "aur build -R" behavior means I have to do it manually after an "aur sync".

This was added in 2.3.0. See: https://github.com/AladW/aurutils/pull/521

Last edited by Alad (2019-03-04 12:15:26)

zf · 2019-03-04 21:12:19

With regards to resetting to the AUR revision (i.e. overwriting build files?), here's what I did:

1) Establish a clean slate: pacman -Rns polybar, remove package from pacman cache and from repo via repo-remove, as well as remove build files in the default location ~/.cache/aurutils/sync
2) aur sync -cu polybar, ranger ($AUR_PAGER) gets launched and I edit PKGBUILD, then save and quit
3) before building the package finishes, I terminate the process
4) repeat step 2, only to realize the PKGBUILD contains my changes and is not the untouched one from the AUR

With regards to aur build -R, it's not documented in the latest version of aurutils.

Jason P. · 2019-03-06 15:48:48

Hi. I'm trying to understand chroot builds but I have kind of basic doubts:

1)

➜ # ~  arch-nspawn /var/cache/build/x86_64/root pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community                               4.9 MiB  6.21M/s 00:01 [###################################] 100%
 multilib is up to date
error: failed retrieving file 'linux-rt.db' from disk : Couldn't open file /home/aurpkgs/linux-rt.db
error: failed to update linux-rt (download library error)
error: failed to synchronize all databases

This update of the base chroot should have worked? I think I did it before like this without problems, for example to install some packages inside the root container before building. Of course inside root/home/aurpkgs there's no file.

This is my pacman.conf inside the root container:

➜ # x86_64  cat root/etc/pacman.conf 
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
HoldPkg = pacman
HoldPkg = glibc
Architecture = x86_64
UseDelta = 0.000000
CleanMethod = KeepInstalled
SigLevel = PackageRequired
SigLevel = PackageTrustedOnly
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustedOnly
LocalFileSigLevel = PackageOptional
LocalFileSigLevel = PackageTrustedOnly
[core]
Usage = All
Server = https://mirror.f4st.host/archlinux/core/os/x86_64
Server = https://mirror.pseudoform.org/core/os/x86_64
Server = https://mirror.cyberbits.eu/archlinux/core/os/x86_64
Server = https://mirror.aur.rocks/core/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/core/os/x86_64
[extra]
Usage = All
Server = https://mirror.f4st.host/archlinux/extra/os/x86_64
Server = https://mirror.pseudoform.org/extra/os/x86_64
Server = https://mirror.cyberbits.eu/archlinux/extra/os/x86_64
Server = https://mirror.aur.rocks/extra/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/extra/os/x86_64
[community]
Usage = All
Server = https://mirror.f4st.host/archlinux/community/os/x86_64
Server = https://mirror.pseudoform.org/community/os/x86_64
Server = https://mirror.cyberbits.eu/archlinux/community/os/x86_64
Server = https://mirror.aur.rocks/community/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/community/os/x86_64
[multilib]
Usage = All
Server = https://mirror.f4st.host/archlinux/multilib/os/x86_64
Server = https://mirror.pseudoform.org/multilib/os/x86_64
Server = https://mirror.cyberbits.eu/archlinux/multilib/os/x86_64
Server = https://mirror.aur.rocks/multilib/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/multilib/os/x86_64
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
[linux-rt]
Usage = All
SigLevel = PackageOptional
SigLevel = PackageTrustAll
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustAll
Server = file:///home/aurpkgs

I don't know why there's an entry for [linux-rt] there. The last package I've built was a rt kernel but I was not expecting something like this in the *base* chroot...

2) Some files inside the copy chroot are owned by a build user and some others by root. Is this normal?

➜ # x86_64  l
total 16K
drwxr-xr-x  4 build build 4.0K Mar  6 16:35 .
drwxr-x---  7 build build 4.0K Mar  5 18:16 ..
drwxr-xr-x 22 root  root  4.0K Mar  5 19:11 build
-rw-r--r--  1 root  root     0 Mar  5 19:10 build.lock
drwxr-xr-x 16 root  root  4.0K Feb 26 17:31 root
-rw-r--r--  1 root  root     0 Mar  5 19:10 root.lock

➜ # x86_64  l build
total 96K
drwxr-xr-x 22 root  root  4.0K Mar  5 19:11 .
drwxr-xr-x  4 build build 4.0K Mar  6 16:35 ..
-rw-r--r--  1 root  root     3 Feb 26 17:31 .arch-chroot
lrwxrwxrwx  1 root  root     7 Dec  6 15:19 bin -> usr/bin
drwxr-xr-x  2 root  root  4.0K Dec  6 15:19 boot
drwxr-xr-x  3 build build 4.0K Mar  5 19:11 build
-rwxr-xr-x  1 root  root   335 Mar  5 19:11 chrootbuild
drwxr-xr-x  2 root  root  4.0K Feb 26 17:30 dev
drwxr-xr-x 35 root  root  4.0K Mar  5 19:11 etc
drwxr-xr-x  3 root  root  4.0K Feb 27 13:53 home
lrwxrwxrwx  1 root  root     7 Dec  6 15:19 lib -> usr/lib
lrwxrwxrwx  1 root  root     7 Dec  6 15:19 lib64 -> usr/lib
drwxr-xr-x  2 build build 4.0K Mar  5 20:41 logdest
drwxr-xr-x  2 root  root  4.0K Dec  6 15:19 mnt
drwxr-xr-x  2 root  root  4.0K Dec  6 15:19 opt
drwxr-xr-x  2 build build 4.0K Mar  5 20:41 pkgdest
dr-xr-xr-x  2 root  root  4.0K Feb 26 17:30 proc
drwxr-x---  3 root  root  4.0K Feb 26 17:31 root
drwxr-xr-x  2 root  root  4.0K Feb 26 17:30 run
lrwxrwxrwx  1 root  root     7 Dec  6 15:19 sbin -> usr/bin
drwxr-xr-x  2 build build 4.0K Mar  5 19:11 srcdest
drwxr-xr-x  2 build build 4.0K Mar  5 19:11 srcpkgdest
drwxr-xr-x  4 root  root  4.0K Feb 26 17:30 srv
drwxr-xr-x  2 build build 4.0K Mar  5 19:11 startdir
dr-xr-xr-x  2 root  root  4.0K Feb 26 17:30 sys
drwxrwxrwt  2 root  root  4.0K Feb 26 17:30 tmp
drwxr-xr-x  9 root  root  4.0K Mar  5 19:11 usr
drwxr-xr-x 12 root  root  4.0K Feb 26 17:30 var

3) How can I install optional dependencies with aur-build command when building in chroot?

Last edited by Jason P. (2019-03-06 15:58:56)

qinohe · 2019-03-06 21:48:04

@jason, you need to read those man pages more thoroughly
Have a look at 'man aur-chroot':

--no-build
Update or create the /root copy of the container; do not build a package.

Jason P. · 2019-03-06 23:35:47

qinohe wrote:

@jason, you need to read those man pages more thoroughly
Have a look at 'man aur-chroot':
--no-build
Update or create the /root copy of the container; do not build a package.

Sorry @qinohe, which one of my 3 questions are you referring to? Are you suggesting to recreate the root copy? Of course I could remove both chroot directories and move on but I would like to learn something with all this. I think my previous doubts/questions are still valid.

qinohe · 2019-03-06 23:54:36

It was an answer to your first question;)
Your second question was already answered in post #289
The third Q., they are installed automatically, far as I know, or I don't understand what you mean..

Alad · 2019-03-07 11:36:06

Jason P. wrote:

1)
➜ # ~  arch-nspawn /var/cache/build/x86_64/root pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community                               4.9 MiB  6.21M/s 00:01 [###################################] 100%
 multilib is up to date
error: failed retrieving file 'linux-rt.db' from disk : Couldn't open file /home/aurpkgs/linux-rt.db
error: failed to update linux-rt (download library error)
error: failed to synchronize all databases
This update of the base chroot should have worked? I think I did it before like this without problems, for example to install some packages inside the root container before building. Of course inside root/home/aurpkgs there's no file.

To access your local repo in the container, you either need to bind mount it or have it specified as a CacheDir (in which case devtools bind mounts it automatically). See "Accessing the local repository" in man aur-chroot.

2) Some files inside the copy chroot are owned by a build user and some others by root. Is this normal?

Yes, makechrootpkg runs "su build makepkg".

3) How can I install optional dependencies with aur-build command when building in chroot?

optdepends are meant to specify packages which are optional at runtime. If you want to use them at build time, change them to depends or makedepends.

Alad · 2019-03-07 12:00:43

zf wrote:

With regards to resetting to the AUR revision (i.e. overwriting build files?), here's what I did:
1) Establish a clean slate: pacman -Rns polybar, remove package from pacman cache and from repo via repo-remove, as well as remove build files in the default location ~/.cache/aurutils/sync
2) aur sync -cu polybar, ranger ($AUR_PAGER) gets launched and I edit PKGBUILD, then save and quit
3) before building the package finishes, I terminate the process
4) repeat step 2, only to realize the PKGBUILD contains my changes and is not the untouched one from the AUR
With regards to aur build -R, it's not documented in the latest version of aurutils.

I see what you mean now. aur-sync does the following:

1. reset the git repository
2. present the repository and patches to the user
3. build the package

Changes after 1. would then be preserved. If you don't want changes, I'm not sure why you'd simply not edit the PKGBUILD though. Undoing changes directly after they were done in an editor is unexpected at best.

Jason P. · 2019-03-07 12:50:01

@Alad Many thanks for your supportive answer

1) I will investigate a little bit further on this. The reason I've asked is that installing packages inside the root container ("# arch-nspawn /var/cache/build/x86_64/root pacman -S <package>") has worked for me before. My local repo is indeed specified as CacheDir but it's also true that now I have one more local repo that didn't existed back in time. So I'm gonna play around with this and spot differences.

3) I didn't explain myself well enough although you offer a possible solution. I was referring to build dependencies for a package that is built inside a container. How to have them inside without manually adding them before the build process. I'll try what you have pointed out and add them to the makedepends array.

This leads me to a new question. Let's say I do a couple of edits in a PKGBUILD that I want to persist every time I build a new version of that package. How do you guys keep track of those customizations? Separated git branches for example? Another AUR tool?

Alad · 2019-03-07 13:02:33

In your pacman.conf you have /var/cache/pacman/aur as CacheDir, but file:///home/aurpkgs as Server for the [linuxrt] repository. I'm guessing you made some changes at one point but forgot some lines.

As to the build dependencies, aur-build adds them to the local repo which is (or should be) available in the container. These are then pulled in by 'makepkg -s'.

Let's say I do a couple of edits in a PKGBUILD that I want to persist every time I build a new version of that package. How do you guys keep track of those customizations? Separated git branches for example? Another AUR tool?

You could maintain your own branch and "git fetch; git rebase master" changes occasionally, and use aur-build.

Since aur-sync does not account for that, you can append the relevant pkgnames to ~/.config/aurutils/sync/ignore

Last edited by Alad (2019-03-07 13:10:03)

qinohe · 2019-03-07 13:39:07

Alad wrote:

Jason P. wrote:
1)
➜ # ~  arch-nspawn /var/cache/build/x86_64/root pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community                               4.9 MiB  6.21M/s 00:01 [###################################] 100%
 multilib is up to date
error: failed retrieving file 'linux-rt.db' from disk : Couldn't open file /home/aurpkgs/linux-rt.db
error: failed to update linux-rt (download library error)
error: failed to synchronize all databases
This update of the base chroot should have worked? I think I did it before like this without problems, for example to install some packages inside the root container before building. Of course inside root/home/aurpkgs there's no file.
To access your local repo in the container, you either need to bind mount it or have it specified as a CacheDir (in which case devtools bind mounts it automatically). See "Accessing the local repository" in man aur-chroot.

Right, I also need to read better myself:(.. I saw the update failed and thought a 'aur chroot --no-build' solves that not noticing you want to access it, my bad...

Jason P. · 2019-03-07 13:56:43

@qinohe No big deal

@Alad That pacman.conf it is the one inside the root container, just in case you were thinking it's my system's one. /home/aurpkgs is bind mounted at boot to /var/cache/pacman/aur. Two local repos reside in that server location although I started using only one.

Alad · 2019-03-07 18:31:26

I don't know what the issue is then. Maybe it's something to do with the bind mount. I've removed that "trick" again from the man page.

Jason P. · 2019-03-07 20:04:35

Alad wrote:

I don't know what the issue is then. Maybe it's something to do with the bind mount. I've removed that "trick" again from the man page.

I don't think it's related because I have the bind mount in my /etc/fstab since the beginning without problems. Maybe I did something that changed the root container or it could be that this happened after adding a second local repo in the very same directory.

It's difficult to know and for the moment I have enough learning of chroot, aurutils and so on hehe. I've just created a new clean root container:

➜ % ~  sudo -u build aur chroot -D /var/cache/build/x86_64 --no-build

This time pacman.conf in the chroot looks fine and there is no presence of any other local repo on it. I could also install some packages inside without any problem.

➜ # x86_64  cat root/etc/pacman.conf 
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
HoldPkg = pacman
HoldPkg = glibc
Architecture = x86_64
UseDelta = 0.000000
CleanMethod = KeepInstalled
SigLevel = PackageRequired
SigLevel = PackageTrustedOnly
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustedOnly
LocalFileSigLevel = PackageOptional
LocalFileSigLevel = PackageTrustedOnly
[core]
Usage = All
Server = https://mirrors.n-ix.net/archlinux/core/os/x86_64
Server = https://mirror.orbit-os.com/archlinux/core/os/x86_64
Server = https://ftp.halifax.rwth-aachen.de/archlinux/core/os/x86_64
Server = https://mirror.csclub.uwaterloo.ca/archlinux/core/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/core/os/x86_64
[extra]
Usage = All
Server = https://mirrors.n-ix.net/archlinux/extra/os/x86_64
Server = https://mirror.orbit-os.com/archlinux/extra/os/x86_64
Server = https://ftp.halifax.rwth-aachen.de/archlinux/extra/os/x86_64
Server = https://mirror.csclub.uwaterloo.ca/archlinux/extra/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/extra/os/x86_64
[community]
Usage = All
Server = https://mirrors.n-ix.net/archlinux/community/os/x86_64
Server = https://mirror.orbit-os.com/archlinux/community/os/x86_64
Server = https://ftp.halifax.rwth-aachen.de/archlinux/community/os/x86_64
Server = https://mirror.csclub.uwaterloo.ca/archlinux/community/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/community/os/x86_64
[multilib]
Usage = All
Server = https://mirrors.n-ix.net/archlinux/multilib/os/x86_64
Server = https://mirror.orbit-os.com/archlinux/multilib/os/x86_64
Server = https://ftp.halifax.rwth-aachen.de/archlinux/multilib/os/x86_64
Server = https://mirror.csclub.uwaterloo.ca/archlinux/multilib/os/x86_64
Server = https://jpn.mirror.pkgbuild.com/multilib/os/x86_64
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/

I'd expect that from now on, calling 'sudo -u build aur build -c ...' will create/update the build chroot while keeping the master root untouched. It will mount also both CacheDir and/or the local repo specified with '-d' flag, so any package needed during the build and existing in that local repo would be installed fine. Fingers crossed hehe.

Many thanks for your help!

Alad · 2019-03-07 23:23:03

Related: if you're using aurutils-git, PR #544 broke the pacman.conf in the chroot. See https://github.com/AladW/aurutils/pull/545 for a fix.

Last edited by Alad (2019-03-07 23:23:18)

Jason P. · 2019-03-08 20:53:20

I've checked doing a new build: 'aur buid -c -d linux-rt ...' and the repo gets added to pacman.conf in both containers, build and root. Is this a bug? I was expecting the root container to not be touched by the build.

➜ # x86_64  tail build/etc/pacman.conf 
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
[linux-rt]
Usage = All
SigLevel = PackageOptional
SigLevel = PackageTrustAll
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustAll
Server = file:///home/aurpkgs

➜ # x86_64  tail root/etc/pacman.conf 
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/aur/
[linux-rt]
Usage = All
SigLevel = PackageOptional
SigLevel = PackageTrustAll
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustAll
Server = file:///home/aurpkgs

One more thing... The package I've tried to build has a sudo call in its PKGBUILD. That call fails because 'builduser' doesn't have enough rights. How could I solve this? If I manually edit sudoers I imagine it will be overwritten on the next build.

Forget about the sudo call. I can run the command outside the container prior to the build.

Last edited by Jason P. (2019-03-08 23:11:44)

Alad · 2019-03-14 18:28:35

I've checked doing a new build: 'aur buid -c -d linux-rt ...' and the repo gets added to pacman.conf in both containers, build and root. Is this a bug? I was expecting the root container to not be touched by the build.

On each build, the build container is rsync'd from the root. If the pacman.conf with the local repository you specified on the command-line isn't in the root's pacman.conf, it won't be in the build's either.

Alad · 2019-03-14 18:30:21

Support for aur-sync/aur-fetch --tar will be removed in the next release, see: https://github.com/AladW/aurutils/pull/548

Alad · 2019-03-17 11:07:39

I made a huge mess in git, so the checksums of the 2.3.1 archive have changed. The AUR PKGBUILD was updated accordingly. If you use aurutils-git, you should rebuild the package as well, e.g. with aur build -f.

hakunamatata · 2019-03-20 08:23:58

When I switched from yay to aurutils, I followed the instructions in the man pages and set up two separate local repositories. Essentially, my pacman.conf looks like this:

[options]
CacheDir = /var/cache/pacman/pkg
CacheDir = /var/cache/pacman/aur
CacheDir = /var/cache/pacman/aur-vcs
CleanMethod = KeepCurrent

[aur]
SigLevel = Optional TrustAll
Server = file:///var/cache/pacman/aur

[aur-vcs]
SigLevel = Optional TrustAll
Server = file:///var/cache/pacman/aur-vcs

Although, I have to admit I am not quite sure what advantages of separate repositories might be. Can anyone point out advantages of setting up a separate repository for VCS packages?

Last edited by hakunamatata (2019-03-28 13:43:07)

Masin AD · 2019-04-01 10:37:33

I have three machines running Arch Linux with several packages each from aur. I thought the moment has come to host a LAN local repository. Up until now I used yaourt and pacaur besides the intended git clone / makepkg workflow. I found out about aurutils in the thread for pacaur and want to give it a try.

Besides my Arch Linux machines, there is a Debian home server which runs 24/7. It should be the obvious choice if not for Debian. But there are containers! So I set up a systemd-nspawn container running Arch Linux. In the container I installed aurutils (and nginx for distributing the packages later). I created a dedicated user for building as makepkg doesn't allow running as root. But now I have several problems:

It's not obvious how to download and build packages. At the moment, I guess I have to aur fetch [package] and aur build in the created folder. But as it's a container on a server it's not a complete desktop environment and so aur build wants to pull in a complete environment[1]
aur sync [package], although fetching the aur package, also tries to pull in all installation dependencies, At least I can't imagine having wayland as a build dependency, but I could be wrong.
aur chroot looks like what I want to keep my repository container clean, but it tries to bind mount /dev in its nspawn container which fails.[2] Maybe that's because of btrfs and permissions.

Any hints how to proceed?

[1]

[aur@aur vivaldi]$ aur build
Running makepkg --clean --syncdeps
==> Making package: vivaldi 2.4.1488.35-1 (Mon Apr  1 12:04:22 2019)
==> Checking runtime dependencies...
==> Installing missing dependencies...
:: There are 10 providers available for ttf-font:
:: Repository extra
   1) noto-fonts  2) ttf-bitstream-vera  3) ttf-caladea  4) ttf-carlito  5) ttf-croscore  6) ttf-dejavu
   7) ttf-freefont
:: Repository community
   8) ttf-droid  9) ttf-liberation  10) ttf-ubuntu-font-family

Enter a number (default=1): 1
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: harfbuzz will be installed before its freetype2 dependency
warning: dependency cycle detected:
warning: libglvnd will be installed before its mesa dependency

Packages (84) adobe-source-code-pro-fonts-2.030ro+1.050it-5  adwaita-icon-theme-3.32.0-1  at-spi2-atk-2.32.0-1
              at-spi2-core-2.32.0-1  atk-2.32-1  avahi-0.7+18+g1b5f401-1  cairo-1.16.0-2  cantarell-fonts-1:0.111-1
              colord-1.4.4-1  dconf-0.32.0-1  fontconfig-2:2.13.1+12+g5f5ec56-1  freetype2-2.10.0-1  fribidi-1.0.5-1
              gdk-pixbuf2-2.38.1-1  glib-networking-2.60.0.1-1  graphite-1:1.3.13-1
              gsettings-desktop-schemas-3.32.0-2  gtk-update-icon-cache-1:3.24.7+25+g17665f06e3-1  harfbuzz-2.4.0-1
              jasper-2.0.16-1  js52-52.9.0-2  json-glib-1.4.4-1  lcms2-2.9-1  libcanberra-0.30+2+gc0620e4-2
              libdaemon-0.14-4  libdatrie-0.2.12-1  libdrm-2.4.97-1  libepoxy-1.5.3-1  libglvnd-1.1.1-1
              libgudev-232-1  libgusb-0.3.0-1  libjpeg-turbo-2.0.2-1  libogg-1.3.3-3  libomxil-bellagio-0.9.3-2
              libpciaccess-0.14-1  libpng-1.6.36-1  libproxy-0.4.15-8  librsvg-2:2.44.13-1  libsoup-2.66.0-1
              libthai-0.1.28-1  libtiff-4.0.10-1  libunwind-1.3.1-1  libvorbis-1.3.6-1  libx11-1.6.7-1
              libxau-1.0.9-1  libxcb-1.13.1-1  libxcomposite-0.4.5-1  libxcursor-1.2.0-1  libxdamage-1.1.5-1
              libxdmcp-1.1.3-1  libxext-1.3.4-1  libxfixes-5.0.3-2  libxft-2.3.3-1  libxi-1.7.9-2
              libxinerama-1.1.4-1  libxkbcommon-0.8.4-1  libxrandr-1.5.2-1  libxrender-0.9.10-2  libxshmfence-1.3-1
              libxtst-1.2.3-2  libxxf86vm-1.1.4-2  llvm-libs-8.0.0-1  lm_sensors-3.5.0-1  mesa-19.0.1-2  nspr-4.21-1
              pango-1:1.43.0-1  pixman-0.38.0-2  polkit-0.115+24+g5230646-1  rest-0.8.1-1
              sound-theme-freedesktop-0.8-3  tdb-1.3.18-2  wayland-1.17.0-1  wayland-protocols-1.17-1
              xcb-proto-1.13-2  xkeyboard-config-2.26-2  xorgproto-2018.4-1  alsa-lib-1.1.8-1
              gtk3-1:3.24.7+25+g17665f06e3-1  hicolor-icon-theme-0.17-1  libcups-2.2.11-1  libxss-1.2.3-1
              noto-fonts-20190111-1  nss-3.43-1  shared-mime-info-1.12-1

Total Download Size:   102.58 MiB
Total Installed Size:  456.81 MiB

:: Proceed with installation? [Y/n]

[2]

[aur@aur ~]$ sudo aur chroot -D buildenv --no-build
Create subvolume '/home/aur/buildenv/root'
==> Creating install root at /home/aur/buildenv/root
mount: /home/aur/buildenv/root/dev: permission denied.
==> ERROR: failed to setup chroot /home/aur/buildenv/root
==> ERROR: Failed to install all packages

Alad · 2019-05-09 18:20:05

Sorry, I haven't checked in this thread for a while.

Although, I have to admit I am not quite sure what advantages of separate repositories might be. Can anyone point out advantages of setting up a separate repository for VCS packages?

Mostly logistical reasons. For example, I have one repository with packages modified from the official repositories which I place at the top of pacman.conf, and two others for AUR packages (one for "base packages", and another for testing purposes which I clear out periodically) which are placed at the bottom.

Besides my Arch Linux machines, there is a Debian home server which runs 24/7. It should be the obvious choice if not for Debian

I have never tried this use case so can't assist you with any problems. If you just want to not keep dependencies installed, you can however use --rmdeps with aur sync. (See the man page why it's not enabled by default)

Last edited by Alad (2019-05-09 18:20:43)

progandy · 2019-05-09 18:52:51

Masin AD wrote:

[*]aur sync [package], although fetching the aur package, also tries to pull in all installation dependencies, At least I can't imagine having wayland as a build dependency, but I could be wrong.[/*]

Most packages are needed for their header files and libraries to include and link against during the build process. There may be some exceptions few and far between, but they are not worth the effort to separate.

Arch Linux

#301 2019-03-02 21:04:56

Re: aurutils - helper tools for the aur

#302 2019-03-04 03:44:36

Re: aurutils - helper tools for the aur

#303 2019-03-04 12:04:24

Re: aurutils - helper tools for the aur

#304 2019-03-04 21:12:19

Re: aurutils - helper tools for the aur

#305 2019-03-06 15:48:48

Re: aurutils - helper tools for the aur

#306 2019-03-06 21:48:04

Re: aurutils - helper tools for the aur

#307 2019-03-06 23:35:47

Re: aurutils - helper tools for the aur

#308 2019-03-06 23:54:36

Re: aurutils - helper tools for the aur

#309 2019-03-07 11:36:06

Re: aurutils - helper tools for the aur

#310 2019-03-07 12:00:43

Re: aurutils - helper tools for the aur

#311 2019-03-07 12:50:01

Re: aurutils - helper tools for the aur

#312 2019-03-07 13:02:33

Re: aurutils - helper tools for the aur

#313 2019-03-07 13:39:07

Re: aurutils - helper tools for the aur

#314 2019-03-07 13:56:43

Re: aurutils - helper tools for the aur

#315 2019-03-07 18:31:26

Re: aurutils - helper tools for the aur

#316 2019-03-07 20:04:35

Re: aurutils - helper tools for the aur

#317 2019-03-07 23:23:03

Re: aurutils - helper tools for the aur

#318 2019-03-08 20:53:20

Re: aurutils - helper tools for the aur

#319 2019-03-14 18:28:35

Re: aurutils - helper tools for the aur

#320 2019-03-14 18:30:21

Re: aurutils - helper tools for the aur

#321 2019-03-17 11:07:39

Re: aurutils - helper tools for the aur

#322 2019-03-20 08:23:58

Re: aurutils - helper tools for the aur

#323 2019-04-01 10:37:33

Re: aurutils - helper tools for the aur

#324 2019-05-09 18:20:05

Re: aurutils - helper tools for the aur

#325 2019-05-09 18:52:51

Re: aurutils - helper tools for the aur

Board footer