You are not logged in.
Thanks Alad. I'm not really a fan of using PKGDEST since additional hacky code would be required to respect the original value of defined (I guess storing it then moving packages around), but that might be a start for something more robust.
As said by Xyne in the bauerbill thread, a more adequate solution could be to brought back part of the original --pkg code in makepkg. It is unclear to me if the installation part of that feature also proved to be error prone, but I didn't bother asking details when I read that post from Allan back in the day. The subsequent more specific question of Xyne stayed unanswered too.
Last edited by Spyhawk (2017-09-07 11:10:51)
Offline
I've been user of cower since installing arch few years ago, but now I want an AUR helper which helps **minimizing user interaction at prompt**. However I want to keep my basic workflow as much as possible and use pacaur on top of that.
I've a ~/.AURrepo which basically is the folder contains the PKGBUILDS, sources and packages. when I use cower I just do these:
cd $HOME/.AURrepo/
cower -df xyz
cd xyz
makepkg -sc && pacman -U
This has been my workflow. Now I want to use pacaur on top of this and make it more automated. For example I just like to issue pacaur -y xyz abc efg and then it handle at least downloading PKGBUILDs into their relevant folder (i.e. ~/.AURrepo/xyz/ ~/.AURrepo/abc/ ~/.AURrepo/efg/, build them (skip if get error and report) and that's enough for me. If it could sudo and pacman -U them this would be great but to me the first two step are more important.
So to achieve this I've set different environmental variables pacaur uses to download and build packages to the current .AURrepo. I've addes these to my profile:
AURDEST=/home/sadid/.AURrepo
PKGDEST=/home/sadid/.AURrepo
SRCDEST=/home/sadid/.AURrepo
LOGDEST=/home/sadid/.AURrepo
BUILDDIR=/home/sadid/.AURrepo
But it seems pacaur doesn't follow them and I had to even symlink .cache/pacur to ~/AURrepo/ When I try to install a package or lists of package I encounter git error. Is there a way to use pacaur consistent with this workflow? I like to keep all AUR related stuff (src, packages, PKGBuilds, …) in one directory organized by package name as folder (the way cower does).
Is there any offer or solution?
Offline
I'm using a similar setup by simply using AURDEST="/my/path", so it should work - check that variable is correctly propagated in your shell.
You don't need to redefine PKGDEST, SRCDEST, etc. if you keep using the same directory - I'd also advise to define these in makepkg,conf instead.
The git errors seemed to have been a temporary server issue (err 502). I cannot reproduce on my end at this time so it should have been fixed now.
Last edited by Spyhawk (2017-09-23 09:26:32)
Offline
Thanks, for your reply and for awesome pacaur.
Now with your help I'm able to at least download packages to my AURrepo. I unset all above variables and just set AURDEST as you said. I tried to configure makepkg.conf as well but with it set based on Arch wiki I get the below error:
(1/1) Arming ConditionNeedsUpdate...
==> Retrieving sources...
==> ERROR: /home/sadid/.AURrepo/tomighty is not a clone of git://github.com/tomighty/tomighty.git
Aborting...
This error seems to be due to my configuration since I've exact same error when I try manual. here is the configured ~/.config/pacman/makepkg.conf
#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
PKGDEST=/home/sadid/.AURrepo
#-- Source cache: specify a fixed directory where source files will be cached
SRCDEST=/home/sadid/.AURrepo
#-- Source packages: specify a fixed directory where all src packages will be placed
SRCPKGDEST=/home/sadid/.AURrepo
#-- Log files: specify a fixed directory where all log files will be placed
LOGDEST=/home/sadid/.AURrepo
when I switched these off (for example just keep the PKGDEST and SRCPKGDEST) or combination these variables (but not all) I get the below error (while manual makepkg do the job):
✘ sadid@Hst ~ pacaur -y tomighty
:: resolving dependencies...
:: looking for inter-conflicts...
AUR Packages (1) tomighty-0.7.2-1
:: Proceed with installation? [Y/n] y
:: Retrieving package(s)...
fatal: Not a git repository (or any parent up to mount point /run/media/sadid)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
/usr/bin/pacaur: line 1062: .git/HEAD.prev: No such file or directory
fatal: Not a git repository (or any parent up to mount point /run/media/sadid)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
:: View tomighty PKGBUILD? [Y/n] n
Offline
Your defined AURDEST directory seems to be on a separate disk mounted at /run/media/sadid. Check the filesystem of that location. I've heard git doesn't work nice across different filesystems, especially NTFS.
Offline
Yeah, you're absolutely right. I've my home directory on a limited SSD device and huge directories like AURrepo are symlinked to a mounted (BtrFs) partition. I'll try a workaround.
Thanks for everything
Offline
If space is an issue, you might want to set AURDEST to the SSD while setting PKGDEST and SRCDEST to your mounted drive. Only the git clone (PKGBUILD and related files only) will be stored in AURDEST, while the heavy downloaded files will be kept in SRCDEST.
Offline
Every single time I run "pacaur -Syu" it always wants to update openbox-multihead-git despite the fact that the project hasn't been updated in years. If I let it go ahead with the update, it still wants to update it again next time. I'm not certain if this is a bug in pacaur or a problem with the openbox-multihead package, but I wanted to start trying to figure out how to fix this - any help gratefully received.
Offline
Well, have you actually looked at the update pacaur offers?
The package will currently build 7460.4e7c884b while the .SRCINFO declares 7460.4e7c884
Note the obvious difference between the two versions. This is not anything to do with pacaur.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
If I'm reading this and
man pacaur
correctly, at present I don't want to edit my makepkg.conf. There are several packages I update regularly from the AUR via pacaur - what I want is that the final package *.xz reside in its own directory, and the source and build stuff in a separate directory. I've defined $AURDEST so pacaur is not in $HOME /.cache/pacaur - my question is: I need to define $SRCDEST? or $PKGDEST? so the final install *.xz package is not in the folder where all the build stuff is? The obvious looks like define $PKGDEST.
Thank you for your consideration.
∞ hard times make the strong, the strong make good times, good times make the weak, the weak make hard times ∞
Offline
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Thanks Alad. Reading there it looks like changing either of them affect makepkg as pacaur invokes/honors makepkg, whereas AURDEST isn't part of makepkg, and i don't want makepkg putting things in my pacaur directory when i'm repackaging something.
I know I'm way behind the curve here, got more studying and tinkering to do.
∞ hard times make the strong, the strong make good times, good times make the weak, the weak make hard times ∞
Offline
The current 6-year old code has severe limitations leading to long lasting issues, and a complete overhaul is needed to properly fix them. However, it is clear to me that maintaining a popular helper is not worth the time nor the hassle. Without entering into the details, this has become an unpaid job I dislike more and more - and I've been talking about it for far too long too. As such, this project is now unmaintained.
The stable version will continue to work as it currently does for the foreseeable future, with some issues becoming apparent starting from the pacman 5.1 release. Users are encouraged to move to another solution (see wiki for good alternatives).
Edit: typos
Last edited by Spyhawk (2017-12-15 14:37:16)
Offline
Thank you for your work all these years. I am using it since the beginning and it was a great tool!
Cedric Girard
Offline
Thanks for this fantastic tool!
Arch Linux: The power in your hands!
Offline
@Spyhawk First of all, I appreciate your hard work and pacaur. However, while you made the same announcement at AUR pinned comment[0] on 2016-02-17, the package was updated several times, the latest commit was made four days ago[1] and you have helped us in this forum until recently. Is this your serious retirement message this time?
[0] https://aur.archlinux.org/packages/pacaur/
[1] https://github.com/rmarquis/pacaur/commits/master
Offline
I couldn't pin a new comment for some reason, so I simply replaced the text of the previous pinned comment.
Offline
That makes sense. Thank you for your reply.
Offline
FWIW, someone suggested the following on reddit:
You should consider asking on the forums if someone would volunteer to take care of the issue tracker for you, because it seems like you need a community manager of sorts. I've seen single-dev projects on GitHub where that worked out for the dev to get back some enjoyment out of the project. Outsource the tedious issue tracker/user management to someone else who enjoys dealing with that sort of thing so that you can get back to code for fun.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Thanks but I'll pass. I actually feel relieved not to handle the toxicity of this project, and I have now more time for my others ongoing projects.
Any "volonteer" for that task would have no idea what they are up to anyway.
I'm the first surprised to see at which speed users are migrating to other projects, so properly announcing the end of support was indeed the right call.
Once the PKGBUILDs are removed from the AUR down the road, the built-in warning for obsolete packages will take care of the rest of unaware users.
Note I might do a last release that replaces cower with auracle once mature enough (due to cower info issue and its effect on the AUR server), but that's about it. Not sure how much that would help though; pacaur isn't directly involved in the matter.
Also, many thanks to people that expressed best wishes. Much appreciated!
Offline
Pacaur currently has the highest AUR package popularity rating so this is indeed a sad announcement.
Offline
Spyhawk, thank you for all of the hard work you did. You made pacaur the best AUR helper tool available. While there are alternatives and people are migrating quickly, make no mistake, pacaur was the best.
Offline
Once the PKGBUILDs are removed from the AUR down the road, the built-in warning for obsolete packages will take care of the rest of unaware users
Can you elaborate more on this?
Offline
A warning for foreign packages that aren't found in the AUR is displayed when upgrading. These are usually obsolete packages that can be removed.
Offline
A warning for foreign packages that aren't found in the AUR is displayed when upgrading. These are usually obsolete packages that can be removed.
I mean on the PKGBUILDs eventually being removed from the AUR. When is that supposed to happen? I wasn't aware. What's going to be used instead? Why?
Offline