You are not logged in.
I'm using aurutils-git right now at the latest master (updated from a build a month or so ago) and I'm not sure if I'm using --ignore correctly as it doesn't seem to be working. I've tried creating a plaintext file at ~/.config/aurutils/sync/ignore that has just 'ttf-ms-win10' in it, yet when I run 'aur sync -u' it still finds and tries to update this package. Same results with 'aur sync -u --ignore="ttf-ms-win10"'
Offline
Does it actually list the package in vifm, and try to build it?
Last edited by Alad (2019-05-23 15:26:40)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Ah, it does not. I was thinking it wouldn't show up on the list of updates at all, my mistake.
Offline
I'm really sorry if this is a dumb question but I've tried searching for this everywhere but couldn't find a suitable answer.
How do you get a diff view of the PKGBUILD upon updating a package with all the added/changed/removed lines highlighted in aurutils like you used to get in pacaur?
Everywhere I've searched seems to suggest that aurutils gives a diff view by default in vifm but I only get this instead:
Even the arch wiki seems to suggest that aurutils has PKGBUILD diff view integrated but I still can't seem to get it to work.
Any help would be really appreciated! Thanks!
moderator edit -- replaced oversized image with link.
Pasting pictures and code
Last edited by 2ManyDogs (2019-06-04 16:09:00)
Offline
Hi there, far as I know you can't view a diff with vifm (see man vifm), though you can with vimdiff...
The picture you show is the way it should be.
What sources did you read that suggest you could diff with vifm?
Offline
Not vifm but the comparison table on the arch wiki page for aur helpers shows that aurutils has diff view capability.
Offline
Ah, clear, well I wouldn't know how to do that, vimdiff maybe?
edit: which still isn't an answer to your Q. ;-)
Last edited by qinohe (2019-06-04 17:27:06)
Offline
If the package has already been installed, a diff will be shown in aur-sync if a newer version is available on the AUR. This however only happens on the first invocation, or (in the git version), when vifm exited successfully.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Hmm, must say I use 'aur sync -cu' to update my packages and have vifm installed, though, I have never seen this diff after exit vifm...
Offline
Merging with the aurutils thread
Offline
Hmm, must say I use 'aur sync -cu' to update my packages and have vifm installed, though, I have never seen this diff after exit vifm...
-c shouldn't make a difference. The diff is not shown after vifm exit, but rather inside vifm (as seperate .patch files).
What I meant here is that in the git version, when vifm exits successfully (exit 0), a "marker" is set so that the same diff is not shown on subsequent aur-sync calls. Reversely, when exiting with :cq (exit 1 on vifm) e.g. for an unexpected change, you will still see the diffs when running aur-sync after.
Last edited by Alad (2019-06-05 12:58:02)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Will have a better look next time there's an update for one of the packages, never noticed it, thanks
Offline
Having a strange issue whenever I try to actually build and install with 'aur sync' - it builds fine, and adds itself to the repo without issue, but then fails when running the sync through pacman. Example:
==> Creating package "mutter-performance"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: mutter-performance 3.32.2+43+gb7f158811-4 (zo 28 jul 2019 13:30:17 CEST)
==> Cleaning up...
==> Extracting database to a temporary location...
==> Extracting database to a temporary location...
==> Adding package 'mutter-performance-3.32.2+43+gb7f158811-4-x86_64.pkg.tar.xz'
-> Computing checksums...
-> Removing existing entry 'mutter-performance-3.32.2+43+gb7f158811-3'...
-> Creating 'desc' db entry...
-> Creating 'files' db entry...
==> Creating updated database file '/var/cache/pacman/custom/custom.db.tar'
:: Synchronizing package databases...
error: failed retrieving file 'custom.files' from disk : expected download size exceeded----------------] 0%
error: failed to update custom (download library error)
error: failed to synchronize all databases
I just tried removing all of my repository .db/.db.tar and .files/.files.tar files and rebuilding the repo with repo-add and still had the same issue next time I ran `aur sync -u`. Not really sure where to look here or what caused this as it had been working fine for a while, maybe it doesn't like one of my package files?
Edit: Also worth noting that just running `pacman -Sy` fixes it but I have to run this every time before it will pick up my package updates now, the auto upgrade from `aur sync` never works
Last edited by Vash63 (2019-07-28 13:22:34)
Offline
This issue popped up a few times, but I have no idea on the cause. It might help to do a binary search on your repo (add the first half of the packages, etc.) to see if you can pin it down to a particular package.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
How can I download all source files in the same hard-coded folder while building in chroot?
I've set SRCDEST in ~/.config/pacman/makepkg.conf, /etc/makepkg.conf and /usr/share/devtools/makepkg-x86_64.conf.
I even run aur-build with:
SRCDEST=/path aur build -c
But source files are always downloaded in the directory of the PKGBUILD (same with aur-sync).
SRCDEST is only respected when not building in chroot.
Offline
SRCDEST is only respected when not building in chroot.
SRCDEST should be respected by makechrootpkg. Please try if it works when running extra-x86_64-build directly.
I just tried removing all of my repository .db/.db.tar and .files/.files.tar files and rebuilding the repo with repo-add and still had the same issue next time I ran `aur sync -u`. Not really sure where to look here or what caused this as it had been working fine for a while, maybe it doesn't like one of my package files?
A follow-up on that: https://github.com/AladW/aurutils/pull/595
Still haven't identified the cause, but it should at least prevent builds from failing.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
SRCDEST should be respected by makechrootpkg. Please try if it works when running extra-x86_64-build directly.
extra-x86_64-build doesn't seem to respect SRCDEST set in ~/.config/pacman/makepkg.conf, /etc/makepkg.conf or /usr/share/devtools/makepkg-x86_64.conf. It only works when the command is prefixed with SRCDEST=/path.
Offline
I noticed that in my old chroot, /etc/makepkg.conf has this appended at the bottom:
BUILDDIR=/build
PKGDEST=/pkgdest
SRCPKGDEST=/srcpkgdest
SRCDEST=/srcdest
LOGDEST=/logdest
MAKEFLAGS='-j8'
PACKAGER='[my name and email address]'
But in a newly created chroot these variables are completely missing.
Edit: In my case it was a misconfiguration in ~/.config/pacman/makepkg.conf, which used "~" to refer to the home directory, but makechrootpkg loads variables as root so it was replaced with "/root" and later on the inexistent directory was replaced with "$PWD". On a different host (with the old chroot) I used full paths instead of "~".
Last edited by lahwaacz (2019-10-19 08:53:31)
Offline
I'm getting errors when using aurutils. e.g. 'aur sync -cu'.
The /var/lib/aurbuild/x86_64/root/etc/pacman.conf gets populated with the following on two separate occasions, the three dots actually replacing many repetitions of the two paths:
[options]
CacheDir = /var/cache/pacman/pkg/ /var/cache/pacman/custom/ /var/cache/pacman/pkg/ /var/cache/pacman/custom/ /var/cache/pacman/pkg/ /var/cache/pacman/custom/ /var/cache/pacman/pkg/ /var/cache/pacman/custom/ ...
It seems that each run appends additional instances of the two paths so the first fresh run goes through, later ones fail due to the excessive CacheDir repetitions.
I'm using a /etc/pacman.d/custom with:
[options]
CacheDir = /var/cache/pacman/pkg
CacheDir = /var/cache/pacman/custom
#CleanMethod = KeepCurrent
[custom]
SigLevel = Optional TrustAll
Server = file:///var/cache/pacman/custom
The /etc/pacman.d/custom is included at the end of the /etc/pacman.conf and the PKGDEST points to /var/cache/pacman/custom
Might this actually be a makechrootpkg issue or something in my particular environment? It has been a while since I've set aurutils up, perhaps some decision I've made is outdated.
This has been happening for a short while now but I didn't have time to look into it right away...
Offline
This is a devtools issue, in particular with arch-nspawn. Please open a report at: https://github.com/archlinux/devtools/issues
Last edited by Alad (2019-10-28 10:25:39)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I would like to get rid of temporary files and log files created by makepkg during aur build. I use aur build to build a package that sources from a remote git repo and thus this repo is cloned during the build process. The problem is that the temporary files and directories are not deleted at the end of the build (i.e. log files and the cloned repo).
That's how I call aur build generally:
aur build -d <myrepo> -a <mylist> --root=<myrootdir> -N [-- <makepkgargs>]
I tested different variants:
(1) Using makechrootpkg and handing over "-c" (=cleanup) to makepkg
aur build -d <myrepo> -a <mylist> --root=<myrootdir> -N -c -- -- -c
Logs and the cloned repo remain after the build, though makepkg should be called with "-c" and without --log (but could be that makechrootpkg calls makepkg always with --log, irrespectively of the fact that I only specific "-c" as makepkg argument)
(2) Using makepkg without any additional argument
aur build -d <myrepo> -a <mylist> --root=<myrootdir> -N
Logs are not written (=OK), the cloned repo is still there (as expected)
(3) Using makepkg with "-c" to force cleanup
aur build -d <myrepo> -a <mylist> --root=<myrootdir> -N -- -c
Logs are not written (=OK), the cloned repo is still there (this shouldn't be the case)
My desired variant is (1). How can I make aur build (makepkg / makechrootpkg respectively) to not create logs and to clean up temporary files?
Thanks,
-- mipi
Offline
makechrootpkg has a fixed set of makepkg options, which cannot be overriden:
https://git.archlinux.org/devtools.git/ … pkg.in#n18
https://git.archlinux.org/devtools.git/ … kg.in#n329
This is different from aur-build, which resets the makepkg arguments (so 3. would run makepkg -c, instead of makepkg -sc). I'd either set LOGDEST to some directory which is deleted after the build, or patch makechrootpkg to fully reset the makepkg arguments.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Since a few days I've had problems with updating packages via aur sync -c, terminating with ==> ERROR: '-d' does not have a valid database archive extension.
This happens with every package, here is a excerpt for updating the aurutils package:
$ aur sync -cf aurutils
==> Using [lanpak] repository
-> aurutils: 2.3.1-1 -> 2.3.2-1
==> Retrieving package files[...]
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found aurutils-2.3.2.tar.gz
-> Found aurutils-2.3.2.tar.gz.asc
==> WARNING: Skipping all source file integrity checks.
==> Extracting sources...
-> Extracting aurutils-2.3.2.tar.gz with bsdtar
==> Starting build()...
m4 -DAUR_LIB_DIR="/usr/lib/aurutils" aur.in >aur
make[1]: Entering directory '/build/aurutils/src/aurutils-2.3.2/completions'
m4 command_opts.m4 bash/aurutils.in >bash/aur
m4 command_opts.m4 zsh/aurutils.in >zsh/_aur
make[1]: Leaving directory '/build/aurutils/src/aurutils-2.3.2/completions'
==> Entering fakeroot environment...
==> WARNING: PACKAGER should have the format 'Example Name <email@address.invalid>'
==> Starting package()...
make[1]: Entering directory '/build/aurutils/src/aurutils-2.3.2/completions'
make[1]: Leaving directory '/build/aurutils/src/aurutils-2.3.2/completions'
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "aurutils"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Adding install file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: aurutils 2.3.2-1 (Fri 01 Nov 2019 06:00:58 AM CET)
==> ERROR: '-d' does not have a valid database archive extension.
Looks to me like it's happening while adding the built package to my custom database. The database is a tar archive, just like in the install instructions of the man page:
lrwxrwxrwx 1 aurpac aurpac 13 Oct 20 05:43 /var/cache/pacman/lanpak/lanpak.db -> lanpak.db.tar
-rw-r--r-- 1 aurpac aurpac 94208 Oct 20 05:43 /var/cache/pacman/lanpak/lanpak.db.tar
-rw-r--r-- 1 aurpac aurpac 94208 Oct 18 16:28 /var/cache/pacman/lanpak/lanpak.db.tar.old
lrwxrwxrwx 1 aurpac aurpac 16 Oct 20 05:43 /var/cache/pacman/lanpak/lanpak.files -> lanpak.files.tar
-rw-r--r-- 1 aurpac aurpac 477696 Oct 20 05:43 /var/cache/pacman/lanpak/lanpak.files.tar
-rw-r--r-- 1 aurpac aurpac 477696 Oct 18 16:28 /var/cache/pacman/lanpak/lanpak.files.tar.old
Though the error looks like it's passing '-d' instead of the database file name at some point. Any suggestions what could have happened?
Offline
Uninstall xdelta3, or build/install the 2.3.2 package by hand with makepkg.
2.3.1 would specify the -d flag to repo-add for .delta, since this was removed in pacman 5.2 I removed it in 2.3.2.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Uninstall xdelta3, or build/install the 2.3.2 package by hand with makepkg.
That did indeed solve my problem, thank you for the quick reply.
Offline