You are not logged in.
That did it! For some reason multilib-testing had been enabled, though I don't remember doing so. It looks like the testing version of lib32-libelf was complaining about not having the testing version of libelf available. Thanks a bunch!
If pacutils has correct stdout/stderr behavior, I can use that instead. Check the output of:
pactrans --sysupgrade --print-only >/dev/null pactrans --sysupgrade --print-only 2>/dev/null
Ran them both, >/dev/null did not output anything and 2>/dev/null did.
Offline
After the git migration and introduction of pkgctl with devtools 1.0.0, it is recommended to recreate all aurutils chroots and update any pacman configuration in /etc/aurutils/pacman-x86_64.conf.
rm -rf /var/lib/aurbuild
cp /usr/share/devtools/pacman.conf.d/extra.conf /etc/aurutils/pacman-x86_64.conf
vim /etc/aurutils/pacman-x86_64.conf # add local repository
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
After the git migration and introduction of pkgctl with devtools 1.0.0, it is recommended to recreate all aurutils chroots and update any pacman configuration in /etc/aurutils/pacman-x86_64.conf.
rm -rf /var/lib/aurbuild cp /usr/share/devtools/pacman.conf.d/extra.conf /etc/aurutils/pacman-x86_64.conf vim /etc/aurutils/pacman-x86_64.conf # add local repository
I have done all of that and also reinstalled devtools, but I still get:
$ aur sync --chroot aurutils
==> Using [aur] repository
-> aurutils (none) -> 15.2-1
==> Retrieving package files
Already up to date.
chroot: /usr/share/devtools/makepkg-x86_64.conf is not a file
Do you have any idea what I'm doing wrong?
Offline
Please try aurutils 15.2
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Please try aurutils 15.2
Argh, thanks! Yes, that helped.
Offline
After updating my system this week-end, I can't seem to get aurutils to function properly. I've followed:
rm -rf /var/lib/aurbuild
cp /usr/share/devtools/pacman.conf.d/extra.conf /etc/aurutils/pacman-x86_64.conf
vim /etc/aurutils/pacman-x86_64.conf # add local repository
adding this at the end of /etc/aurutils/pacman-x86_64.conf:
[aur]
SigLevel = Never
Server = file:///var/cache/pacman/aur
This got me a "/usr/share/devtools/makepkg-x86_64.conf is not a file" error, with aurutils-13.8-1. I figured I may need a more recent aurutils, so I installed version 15.3-1 manually. I now have the following error:
chroot: /var/lib/aurbuild/x86_64/root is not a directory
chroot: did you run aur chroot --create?
Pacman tells me aurutils 15.3-1 is installed, but it's clearly not there in my local database.
Did I update pacman-x86_64.conf incorrectly, or is it the aurutils upgrade that I'm messing up? Thanks in advance for any pointers!
Offline
Please follow the advice given in #477 of this thread.
Offline
I have tried to follow thread #477:
rm -rf /var/lib/aurbuild
cp /usr/share/devtools/pacman.conf.d/extra.conf /etc/aurutils/pacman-x86_64.conf
vim /etc/aurutils/pacman-x86_64.conf # add local repository
as mentioned in my thread. I do believe I added the local repository in /etc/aurutils/pacman-x86_64.conf as I had it in my previous setup.
Maybe I am misunderstanding something. Would you have any pointers?
Offline
I finally got it working. I'd completely botched the last step and then started going in the wrong direction due to my poor understanding of chroot and related processes.
Thanks for bearing with me.
Offline
Hi, updating aurutils to the very latest version (15.5) seems to make the 'aur' binary disappear altogether. Where has it gone?
Or did I miss something obvious?
Edit: I figured the problem out, which I'll explain. Apologies if this is a "newbie" issue, otherwise I think that could be worth discussing.
It turns out that I had exported the $PREFIX env. variable in the terminal session I used for updating aurutils (using 'aur sync -u'), while manually building some software, which made pacman install the updated aurutils into this $PREFIX location.
It's possibly a normal behavior, but certainly something to be careful about. At this point, I don't know if this is normal behavior for pacman, for aurutils or if this is specific to the aurutils package itself.
Last edited by OpusOne (2023-06-05 20:09:07)
Offline
I can't reproduce this...
% pacman -Qi aurutils | grep Version
Version : 15.5-1
% pacman -Ql aurutils | grep /usr/bin
aurutils /usr/bin/
aurutils /usr/bin/aur
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I can't reproduce this...
% pacman -Qi aurutils | grep Version Version : 15.5-1 % pacman -Ql aurutils | grep /usr/bin aurutils /usr/bin/ aurutils /usr/bin/aur
Thanks. I just edited my post while you were replying.
So, again, apologies, as this was my fault. Still, could you answer my point about the $PREFIX env. variable? Is this expected behavior when using AUR packages (or even any pacman package for that matter?)
Offline
When PREFIX is set in the environment, for example by doing PREFIX=... aur-sync ..., then the aurutils Makefile will use it.
To avoid these problems, I set PREFIX and ETCPATH explicitly for the AUR package: https://aur.archlinux.org/cgit/aur.git/ … ab6dcaa147
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Thanks for the very fast fix!
Great tool btw. Simple and effective. I had tried yay before but it was definitely not for me.
Last edited by OpusOne (2023-06-05 21:17:38)
Offline
I am thinking of migrating away from yay to giving aurutils a shot, after having asked here for some guidance.
However, aurutils assumes a local repository is used, while if I understand correctly, packages installed with yay are "foreign packages" (and printed with pacman -Qm).
How would one go about migrating these packages to be managed via this local repository instead?
I found a section "Migrating foreign packages" in the README but do not know if this explanation is still up-to-date.
Removing/Reinstalling everything would probably work, but that would be a heavy-handed solution.
Offline
If the packages are still in yay's cache directory you can move them to the local repository (here assumed to be in /home/custompkgs):
find ~/.cache/yay -iname '*.pkg.tar*' -execdir mv -t /home/custompkgs {} +
cd /home/custompkgs
repo-add custom.db.tar.gz *.pkg.tar*
Then pacman -Syu as usual.
Removed packages I recommend to rebuild, but you can instead use something like https://aur.archlinux.org/packages/fakepkg
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
If the packages are still in yay's cache directory you can move them to the local repository (here assumed to be in /home/custompkgs):
find ~/.cache/yay -iname '*.pkg.tar*' -execdir mv -t /home/custompkgs {} + cd /home/custompkgs repo-add custom.db.tar.gz *.pkg.tar*
Maybe I am overthinking this, but what is the convention here: Should /home/custompkgs be owned by my unpriviledged user, or by root?
Or do most people actually use something else like /home/$USER/custompkgs, or /var/cache/pacman/custompkgs?
It's just that I wouldn't intuitively expect something outside of /home/$USER to be $USER-owned.
Offline
The only important part is that makepkg runs as an unprivileged user, so the local repository should be owned by one. That can be your regular user, or a dedicated user; see https://github.com/AladW/aurutils/blob/ … #L472-L534
/var/cache/pacman/<repo name> is if you want to avoid having a copy of built packages in a separate directory (but has its own drawbacks).
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Hey it's me again.
I'm currently trying to figure out my ideal workflow for upgrading packages and noticed that `aur repo --upgrades` includes packages which are no longer installed I think.
For example jaja11-openjfx. This is no longer tracked via `pacman -Qi`, but resides in `.cache/aurutils/sync`, has a .pkg.tar.zst in `$HOME/custompkgs` (which I subsequently `repo-add`ed) and maybe has data lying around elsewhere.
How do I cleanly remove/untrack this without having aurutils in some inconsistent state afterwards?
Offline
If after uninstalling a package you want to remove it from the local repository as well, you can use aur-remove. The code is listed in man aur
!/bin/sh --
# aur-remove - remove listed packages from all local repositories
if [ "$#" -eq 0 ]; then
printf 'usage: aur remove package [package ...]\n' >&2
exit 1
fi
aur repo --list-path | while read -r repo_path; do
repo-remove "$repo_path" "$@"
paccache -c "${repo_path%/*}" -rvk0 "$@"
done
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Thanks for aurutils Alad! I have one question though. When you use yay or paru you can see the foreign packages using pacman by querying with pacman for foreign packages.
Since with aurutils the AUR packages get added to the sync database you get no output when doing them when having installed an AUR package with aurutils. Is there a way
to list the installed AUR packages that you built and added to your local repo using aurutils, I wasn't abled to find it in the documentation?
Offline
Yes, pacman does have an option for that.
SYNC OPTIONS (APPLY TO -S)
-l, --list
List all packages in the specified repositories. Multiple repositories can be specified on the command line.
$ pacman --sync --list any-repo-listed-in-pacman.conf #long_version
$ pacman -Sl any-repo-listed-in-pacman.conf
Both commands will show exactly the same output : a list of all pacakges in the repo , their version and whether they are installed.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yes, pacman does have an option for that.
$ pacman --sync --list any-repo-listed-in-pacman.conf #long_version $ pacman -Sl any-repo-listed-in-pacman.conf
Both commands will show exactly the same output : a list of all pacakges in the repo , their version and whether they are installed.
I forgot about that one and didn't think to look for that option in the pacman man-page. Thanks for reminding me!
Last edited by inittux (2023-07-17 10:49:19)
Offline
When I call `aur sync --upgrades --no-build`, it opens vifm and shows the package contents and some `.diff` files.
Unfortunately, these .diff files are hard to read since they are created via a simple call to git-diff, which causes it to use difftastic, which I normally use.
The way this is displayed in vifm is however not suitable to make out what's going on.
Is there a way to pass the `--no-ext-diff` flag to `git-diff`, via `aur-sync` -> `aur-view` -> `git-diff`?
I would have shown a screenshot, but of course, the .diff file is not there anymore when you call `aur sync --upgrades --no-build` a second time
Offline
I suppose it depends on how you told git to use diffstatic. If you use GIT_EXTERNAL_DIFF, you can unset that variable prior to running aur-sync (e.g. with env -u). If the setting is in ~/.gitconfig, you could temporarily ignore it with GIT_CONFIG_GLOBAL=/dev/null aur sync ...
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline