You are not logged in.
To get around the permission issues I was having with the newer versions of aurutils, I added a chown command to the beginning of an alias, that would add the proper permissions of my repo just before running
aur sync -u
which worked fine until aurutils was updated to the latest version (2.2.0-1). Now when I run the above command with or without changing permissions, I get
mkdir: cannot create directory '/.cache/aurutils': Permission denied
The directory that it's trying to create already exists, and the permissions are correct (for my user).
It seems with recent updates the functionality (at least how I've been using it with my repo) of aurutils keeps breaking.
EDIT: When I run
sudo aur sync -u
it worked (there were no packages to update). However, when I remove the sudo I get the above error once again, so it seems to be trying to create the directory each time I try to update my repo.
Last edited by tydynrain (2019-01-23 05:06:36)
Registered Linux User: #623501 | Arch Linux Principles: Simplicity - Modernity - Pragmatism - User Centrality - Versatility => KISS
Arch Linux, the most exciting thing since Linus created Linux and married it with GNU/GPL.
Arch Linux for Life, Arch Linux Forever!
Offline
That is weird
'/.cache/aurutils'
Is not this folder supposed to be under your user folder?
Offline
That is weird
'/.cache/aurutils'
Is not this folder supposed to be under your user folder?
It is under my user folder, that's why the permission issue is so bizarre. That and the fact that it seems to be trying to recreate the directory each time I update my repo. Weirdness all around.
Registered Linux User: #623501 | Arch Linux Principles: Simplicity - Modernity - Pragmatism - User Centrality - Versatility => KISS
Arch Linux, the most exciting thing since Linus created Linux and married it with GNU/GPL.
Arch Linux for Life, Arch Linux Forever!
Offline
Why is your home directory '/' and not e.g. '/home/tydynrain'?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
What are your $XDG_CACHE_HOME and $HOME variables? Unless $HOME equals to '/', which is very unlikely, '/.cache/aurutils' is not under your "user folder".
Offline
@WorMzy and @lahwaacz, I just noticed that it is trying to create the directory under /. This is very confusing, as my home directory IS set to /home/tydynrain (with .cache and .config directories), and the previous versions of aurutils (and all other programs of which I'm aware) correctly identifies and adds its directory there. It is only this latest version that seems to want to create it under root.
Last edited by tydynrain (2019-01-24 03:32:02)
Registered Linux User: #623501 | Arch Linux Principles: Simplicity - Modernity - Pragmatism - User Centrality - Versatility => KISS
Arch Linux, the most exciting thing since Linus created Linux and married it with GNU/GPL.
Arch Linux for Life, Arch Linux Forever!
Offline
What is your $XDG_CACHE_HOME variable?
Offline
What is your $XDG_CACHE_HOME variable?
This is likely going to sound stupid, but what is the quickest way to determine that? I've never needed to do that yet, and after some web searches I was not able to find any particular method for finding this information.
The one command that came to my mind was
grep | $XDG_CACHE_HOME
which gives the output
bash: /.cache: Is a directory
which is in root. As to how or why it is set to root, I have no clue. I didn't intentionally do anything to change it from its default location. I have a similar setup on 3 separate Arch installs, so I'll have to check if this issue exists in the other two (the permission issue I mentioned earlier does exist across all 3).
Registered Linux User: #623501 | Arch Linux Principles: Simplicity - Modernity - Pragmatism - User Centrality - Versatility => KISS
Arch Linux, the most exciting thing since Linus created Linux and married it with GNU/GPL.
Arch Linux for Life, Arch Linux Forever!
Offline
lahwaacz wrote:What is your $XDG_CACHE_HOME variable?
This is likely going to sound stupid, but what is the quickest way to determine that? I've never needed to do that yet, and after some web searches I was not able to find any particular method for finding this information.
The one command that came to my mind was
grep | $XDG_CACHE_HOME
which gives the output
bash: /.cache: Is a directory
You're taking the output of the grep command with no options:
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
And piping it as input to the command:
$XDG_CACHE_HOME
This does not work in the first place as grep emits its error to stderr, not stdout.
The second problem is that you tried to execute the contents of the variable rather than, say, `echo` it.
That being said, the error message tells us the contents:
bash: /.cache: Is a directory
bash refused to execute the command "/.cache" because it wasn't a valid command. Along the way this shows that the variable contents are this directory name, and also that is completely broken.
Check your bashrc or similar to find out why it is set that way.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Hi,
I've decided to use aurutils to manage my AUR packages. So far I have a new local repo with an empty db. Next step would be to add my AUR packages on it but I don't longer have the .tar.xz files. Since they were installed with "pacman -U" I guess their info is not stored in pacman's database for [core], [extra] or [community] packages, but I can list them with "pacman -Qm". Where is this info stored? To migrate these AUR packages can I just simply re-build and add them to the new repo database or do I have to remove them first?
Thanks!
Offline
Hi there, I wouldn't make a big deal out of it and just sync the packages for your preferred apps.
Did you know there is a thread for aurutils in #Community Contributions?!
Offline
I like Aurutils very much indeed...
As I understand how it works, once you built a binary package from source, it does not matter if you did it with yay or manually...
If you created and configured Aur-sync correctly, it will search AUR repo, fetch source code and downlaod to ~/.config/aurutils/sync, check missing deps and install them first, then build your package and Aur-sync will also automatically move the new pkg to your custom repo, but it will not issue a pacman --sync pkg command, so that last bit you will have to do it yourself..
Aur-utils does register an entry in your custom repo database files once the package is built and moved to your custom repo folder, so that Pacman can also read that custom database and install pkgs from there,
Pacman actually does have its own database files about the custom Aur-utils repo at:
/var/lib/pacman/sync/
And also keeps mapping of files of each installed package at:
/var/lib/pacman/local/
I am sorry if you already knew this. But anyways, I agree with qinohe.
For example, I installed some packages with yay and they were not recognised by Aur-check (v1.5 at least) and Pacman -Syu (of course), because they were not registered at any common database!
So I uninstalled all of my AUR pkgs with yay ( I don't use that many pkgs from AUR, I'd say that at the time they were about 15 pkgs only) and reinstalled them using Aurutils..
Now, if you do uninstall any AUR pkg with Pacman, Aurutils database will still hold the entry for that pkg. You need either to rebuild you custom database or delete the entries manually...
Also, it seems to me that , sometimes, Aurutils will install dependencies with Pacman before building AUR pkgs but, for some strange reason -maybe myself is to blame- when I remove those pkgs with Pacman, it does not rm all installed deps associated with those AUR pkgs... So yeah, there is some system management to do yourself if you use AUR pkgs and Aur-utils...
But Aur-utils allows me to keep my system tight as I got to learn about most packages of my system and always check for uneeded deps/pkgs/orphans...
Last edited by mountaineerbr (2019-02-26 18:15:28)
Offline
... but I can list them with "pacman -Qm". Where is this info stored?
/var/lib/pacman/local/
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
This is documented in "man aur" under the heading "CREATING A LOCAL REPOSITORY".
> If built packages are available, add them to the database:
Hi,
I've decided to use aurutils to manage my AUR packages. So far I have a new local repo with an empty db. Next step would be to add my AUR packages on it but I don't longer have the .tar.xz files.
Since you do not have built packages available, there is nothing to be added. *Nothing*. Built packages are, in fact, the thing which goes into a repository.
If you would like to create those packages, you may do so regardless of whether you currently have versions of them installed on your system. aur-sync specifies that it builds a package and adds it to the repository -- it does not say that it will stand in your way and refuse to work since you have the package installed.
Remember -- aurutils is a collection of utilities for managing a custom repository. It is not, per se, a collection of utilities merely for updating the packages you currently have installed (whether from a repo or not).
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Merging with the aurutils thread...
Offline
Thank you all for the advices. I'm new to local repositories and this tool requires a bit of understanding of pacman that I didn't have.
So far I've managed to download and build packages with aur sync. It also synced them with pacman for me. I was not expecting that part but maybe it happened because I already have them installed on my system and they first appeared in a repo, the local one for aur.
I've also followed the optional advice found in aur-build man pages for creating a dedicated build user to avoid password prompts.
➜ % ~ sudo -u build aur sync aurutils
This works like a charm but now I'm a bit stucked trying to sync with the '-c' flag, that is on a chroot environment. I've followed the aur-chroot man page section that explains how to avoid password prompts also and added the examples to sudoers config in a drop-in file. For some reason something is not working as expected and I'm asked for the password of the user 'build'.
This is my configuration:
➜ # sudoers.d cat 01_user
user hostname=(build) /usr/bin/aur
➜ # sudoers.d cat 10_build
# aur-build
build hostname=(root) NOPASSWD: /usr/bin/pacman
# aur-chroot
build hostname=(root) NOPASSWD:SETENV: /usr/bin/makechrootpkg
build hostname=(root) NOPASSWD: /usr/bin/mkarchroot, /usr/bin/arch-nspawn
Commented out parts in sudoers file:
##
## User privilege specification
##
root ALL=(ALL) ALL
## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d
➜ # sudoers.d visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/01_user: parsed OK
/etc/sudoers.d/10_build: parsed OK
When I run 'sudo -u build aur sync -c package' I'm first asked for my password (as expected) but after reviewing the PKGBUILD a new prompt asks for user 'build' password with this accompanying message:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for build:
I guess this is for entering the chroot environment... I created the user 'build' as instructed in aur-build man page: 'useradd build --system --shell /sbin/nologin --home-dir /var/cache/build --create-home' and it doesn't have a password yet. I think this is the problem right?
➜ # sudoers.d grep build /etc/shadow
build:!: ..........
Offline
So you user is called 'build' and your hostname is 'hostname'?
The examples are just examples nothing more, use common sense...
I have looked at the man pages briefly and you not following it exactly.
For starters does the environment work if you leave out all that sudo?
I would suggest to first set it up in a simple manner then add all that fancy stuff.
Can't really test it for you though I have set my repo to build and update in chroot.
There's no need for a separate user thus I never need to use a password until install of a package and gladly leave it like this;)
Offline
I've managed to understand what's going on: mkarchroot is trying to create the base directory for chroot. See https://github.com/AladW/aurutils/blob/ … hroot#L112. If no directory option is provided the default "directory=/var/lib/aurbuild/$machine" is used. See also this comment: https://github.com/AladW/aurutils/issue … -384089024
I've ran a test with "aur chroot" passing -D option (base folder) and it works. Now two more questions:
- Is there another way to indicate an alternative path other than -D flag? Perhaps a config file?
- The chroot environment takes some space. Every time I build within a chroot a new one is created? I guess that's the whole point hehe.
Thanks.
Offline
Your first question idk.
The second, I haven't noticed but I think one systemd-nspawn container was created and used for installing and updating packages.
But I could be wrong;)
edit: checked, yes, one container 2 users; root and me
Last edited by qinohe (2019-02-26 17:22:38)
Offline
Just to be clear, you mean that by default the same container is re-used every time?
Offline
No, makechrootpkg has a "master" container called "root" which is used as the clean base-devel system, and it clones that copy to one which is by default named "$USER" in order to install dependencies and suchlike.
It reuses the "$USER" chroot every time, usually you would use makechrootpkg -c to delete and recreate your working copy for each package.
(extra-x86_64-build automates this. So does aurutils' "build" subcommand...)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Ah, thanks @ eschwartz now the 2 users actually make sense;)
Offline
It reuses the "$USER" chroot every time, usually you would use makechrootpkg -c to delete and recreate your working copy for each package (extra-x86_64-build automates this. So does aurutils' "build" subcommand...)
- So, if one is building packages with "aur sync -c", the "$USER" chroot will be used but recreated from master container each time. Is this correct?
- Following previous idea I would expect $USER chroot to not have residual data from previous builds (logs, build artifacts...). Its size should be more or less the same for every build despite of package updates coming from master container. Right?
Thanks.
Last edited by Jason P. (2019-02-27 15:47:52)
Offline
So, if one is building packages with "aur sync -c", the "$USER" chroot will be used but recreated from master container each time. Is this correct?
Confirmed. Every time the same container is reused.
Following previous idea I would expect $USER chroot to not have residual data from previous builds (logs, build artifacts...). Its size should be more or less the same for every build despite of package updates coming from master container. Right?
But not the int way I was expecting. Container is "cleaned" when the build starts because it's cloned again so every leftover from previous builds disappears. I guess with option "temporary container" (makechrootpkg -T) this behaviour changes.
Offline
I just set up a local repo as per the man and set CacheDir to be:
CacheDir = /var/cache/pacman/pkg/
CacheDir = /var/cache/pacman/custom/
CleanMethod = KeepInstalled
Would it be wise to set $PKGDEST in ~/.config/makepkg.conf to be /var/cache/pacman/custom/ to keep everything together, or is there important distinction between CacheDir and $PKGDEST one should know about for a "correct" workflow? I know paccache -c allows different cache directories to be cleaned so there's no benefit to this regard--curious what the workflow of experienced/advanced users are like, e.g. how $PKGDEST, $SRCDEST, and $SRCPKGDEST are used.
Offline