Package Details: aurget 4.7.6-1

Git Clone URL: (read-only, click to copy)
Package Base: aurget
Description: A simple, Pacman-like AUR helper
Upstream URL:
Licenses: GPL
Submitter: brisbin33
Maintainer: brisbin33
Last Packager: brisbin33
Votes: 159
Popularity: 0.57
First Submitted: 2009-11-11 19:37 (UTC)
Last Updated: 2022-02-12 19:11 (UTC)

Dependencies (1)

Required by (0)

Sources (1)

Latest Comments

brisbin33 commented on 2019-09-03 12:59 (UTC)

Thanks novica, should be fixed in the next release.

novica commented on 2019-09-01 09:37 (UTC)

When I run

aurget -Syu

I get a message

:: Starting AUR upgrade... awk: cmd. line:4: warning: regexp escape sequence `\"' is not a known regexp operator

aurget version 4.7.2-1

linux 5.2.11.arch1-1

Alad commented on 2019-05-01 18:47 (UTC) (edited on 2019-05-01 20:29 (UTC) by Alad)

My main motivation was for what's listed in the AUR helper wiki, but you're right that just having the package available here or on github doesn't harm anyone. I've just proposed to remove stale entries from the tables in that article instead. [4] Thanks.


brisbin33 commented on 2019-04-25 20:27 (UTC)

@Alad, I don't follow. Do you want me to take this package down? Delete the code off GitHub? Is its presence somehow causing pain somewhere?

Thanks for those links though, aurutils has some really cool ideas, though a few rough edges and a steep learning curve, IMO.

Alad commented on 2019-03-24 00:24 (UTC) (edited on 2019-03-24 00:25 (UTC) by Alad)

To be blunt, what's the reason to keep using this one? It performs poorly compared to most if not all other AUR helpers [1], has no unique functionality of its own, and encourages brittle practices like sourcing PKGBUILDs [2] over using SRCINFO and the RPC, which have existed since 2012. [3]




brisbin33 commented on 2016-05-06 14:57 (UTC)

Thanks yusefmhg, I've added an Issue on GH: Please track progress there.

yusefmhg commented on 2016-05-06 14:33 (UTC)

I believe there's a bug. When installing a package with a special character in the name (like bisonc++), the tarball can't be retrieved. Seems the problem is the subroutine url_encode being applied twice on the url (which causes the + character to be replaced for %%2b instead of %2b).

AMZ-X commented on 2016-03-03 07:23 (UTC)

Nice AUR helper. Thank you brisbin33.

brisbin33 commented on 2016-03-01 16:59 (UTC)

The --pkg error should be fixed in 4.7.1 Please see the commit message for important implications to split packages:

Leonardo19 commented on 2016-03-01 10:11 (UTC)

The version 4.7.0-1 failed to make packages in my case. Something with makepkg and improper parameter '--pkg'.

brisbin33 commented on 2016-02-29 23:43 (UTC)

Thanks, I think the v5 RPC interface is working in 4.7.0. Please open GitHub issues if not.

xsmile commented on 2016-02-29 13:02 (UTC)

aurweb 4.2.0 was released and it includes a new RPC interface, see

FernandoBasso commented on 2016-02-27 11:26 (UTC) (edited on 2016-02-27 11:40 (UTC) by FernandoBasso)

I believe a small modification needs to be done on aurget because pacman 5 removed --pkg option:

brisbin33 commented on 2015-08-10 12:51 (UTC)

v4.6 updated to work with the AUR v4 at the default domain. Users at v4.5 can use the --aur4 flag to upgrade to v4.6. Users prior to v4.5 will have a small chicken-egg problem, and need to install 4.6 manually as per carstene1ns's comment below.

brisbin33 commented on 2015-08-10 12:04 (UTC)

I'm pushing out an update now to remove the --aur4 option and make its behavior the default. Until then, aurget without the --aur4 option will not work.

commented on 2015-08-09 22:12 (UTC)

The problem is that without the option --aur4, aurget will act as if it's using the old AUR site. Now that aur4 has been moved to aur, arget needs an update. You can see this in /usr/bin/aurget by doing a search for "if aur4".

FernandoBasso commented on 2015-08-09 11:51 (UTC)

@carstene1ns Okay, easy and simple enough. Thanks.

carstene1ns commented on 2015-08-09 11:48 (UTC)

@FernandoBasso: Your old aurget version does likely not handle the new aur4 api correctly and can not download the packages because the URLs to the tarballs (they are now snapshots provided by cgit) changed. A solution would be to download, extract and build manually: $ curl | bsdtar xf - && cd aurget && makepkg -sicf && cd .. && rm -rf aurget/

FernandoBasso commented on 2015-08-09 11:16 (UTC)

---------------------------------------------------------- aurget -Su aurget dropbox --noedit --noconfirm :: Resolving dependencies... :: Searching AUR... Targets (2): aurget-4.5.0-1 dropbox-3.8.5-1 Proceed with installation? [Y/n] Y :: Retrieving taurball from AUR... gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now warning: package aurget failed to download, skipping :: Retrieving taurball from AUR... gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now warning: package dropbox failed to download, skipping --------------------------------------------------------------------- Anyone else experiencing this problem? It happens with some other packages I have tried upgrading as well.

respiranto commented on 2015-07-11 22:29 (UTC)

All right. But not before tomorrow - I got to learn using git first.

brisbin33 commented on 2015-07-11 17:43 (UTC)

Awesome! Would you be interested in opening a PR on github?

respiranto commented on 2015-07-11 17:02 (UTC)

As aurget does not seem to be able to use the AUR4 yet, I have just edited it a little. So in case somebody else wants the same behavior, here's the diff: [code] - 6 AUR='' + 6 AUR='' # AUR4 - 92 printf "$AUR/packages/$(url_encode "${1:0:2}")/$(url_encode "$1")\n" + 92 printf "$AUR/cgit/aur.git\n" # AUR4 - 111 pkgbuild() { get "$(aur_packages_url "$1")/PKGBUILD"; } + 111 pkgbuild() { get "$(aur_packages_url "$1")/plain/PKGBUILD?h=$1"; } # AUR4 - 113 taurball() { get "$(aur_packages_url "$1")/${1}.tar.gz"; } + 113 taurball() { get "$(aur_packages_url "$1")/snapshot/${1}.tar.gz"; } # AUR4 [/code] The URL would obviously have to be changed as soon as the AUR4 uses the default subdomain.

kressi commented on 2015-06-03 21:01 (UTC)

@FernandoBasso I have hade the same problem. aurget uses curl with https. On my system, the problem was caused by a CA file that did not exist. It is defined in curl-config. You can check whether you have the problem with $ curl --fail '' With wrong configs this returned: curl: (77) error setting certificate verify locations: CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none To fix this issue, there should be a solution on

FernandoBasso commented on 2014-12-17 08:05 (UTC)

@brisbin33, I'm sorry, but it is happening again. However, if I open the link from the "HTTP GET" line (from --debug) in the browser, it finds the package. I no longer think it could be a DNS problem. I took an screenshot: I also tried after reinstalling aurget and after mv'ing $HOME/.config/aurgetrc away. Same situation. Mind you that I don't expect you to help me solve this but I felt like posting it here again nonetheless.

brisbin33 commented on 2014-12-15 20:48 (UTC)

Oh good, glad it's working. > I love aurget. Keep up the excellent work. Thanks!

FernandoBasso commented on 2014-12-15 20:47 (UTC)

No problem. It is working fine again. can be retrieved with any browser or command line tool now, so, I guess it might have been a DNS problem or something similar. I'm really sorry for having taken your time. Thanks for the help. I love aurget. Keep up the excellent work.

brisbin33 commented on 2014-12-15 14:33 (UTC)

I'm sorry, I just can't reproduce this. Aurget works fine, and those URLs look fine: % curl # Author: Patrick Brisbin <> pkgname=aurget pkgver=4.4.2 pkgrel=1 pkgdesc="A simple, Pacman-like AUR helper" arch=('any') url="$pkgname" license=('GPL') source=("$pkgname/archive/v$pkgver.tar.gz") optdepends=('customizepkg: for auto-customizing packages') package() { cd "$pkgname-$pkgver" make PREFIX=/usr DESTDIR="$pkgdir" install } md5sums=('58c8d6192b7d5ea9ed7bad6a380bf27d') % curl '\[\]=aurget' {"version":1,"type":"multiinfo","resultcount":1,"results":[{"ID":129291,"Name":"aurget","PackageBaseID":31933,"PackageBase":"aurget","Version":"4.4.2-1","CategoryID":16,"Description":"A simple, Pacman-like AUR helper","URL":"https:\/\/\/pbrisbin\/aurget","NumVotes":156,"OutOfDate":0,"Maintainer":"brisbin33","FirstSubmitted":1257968246,"LastModified":1416843927,"License":"GPL","URLPath":"\/packages\/au\/aurget\/aurget.tar.gz"}]}

FernandoBasso commented on 2014-12-14 10:13 (UTC)

@brisbin33, $ aurget --debug -S aurget [DEBUG] sourcing user configuration from /home/fernando/.config/aurgetrc :: Resolving dependencies... [DEBUG] storing temporary files in /tmp/aurget [DEBUG] HTTP GET [DEBUG] PKGBUILD not found for aurget [DEBUG] setting up 1 targets for processing :: Searching AUR... [DEBUG] HTTP GET\[\]=aurget [DEBUG] target aurget may have moved to repos [DEBUG] legacy PKGBUILD: /tmp/aurget/aurget_PKGBUILD error: target not found: aurget I just noticed that "au" in the first GET HTTP verb line. If I try that link in the browser, there is nothing there indeed. Thanks a lot for your support.

brisbin33 commented on 2014-12-13 17:48 (UTC)

Fernando, Everything's working fine for me. It may have been a temporary network problem with the AUR itself? If you continue to have this issue (and in the future for any issues), can you please gist full --debug output?

FernandoBasso commented on 2014-12-13 09:55 (UTC)

Aurget won't find any packages any longer (not sure when it stopped working). $ aurget -S jdk :: Resolving dependencies... :: Searching AUR... error: target not found: jdk $ aurget -Ss jdk <nothing comes out> I'm using version 4.4.2.

brisbin33 commented on 2014-10-26 21:54 (UTC)

MickeyKnox, v4.4.0 comes with a new configuration variable, eager_sudo, which should help your (and others') scenario. Please check man 5 aurgetrc for details. Thanks

brisbin33 commented on 2014-10-25 12:48 (UTC)

It's unfortunate, but yes expected. If you don't say to keep sources, require sudo password for pacman, and don't enter it in time, what would you expect? It would be nice of makepkg returned unsuccessfully in this case, then aurget would no not to discard sources. It doesn't, so there's not much I can do besides work-arounds that I just haven't implemented yet. Sorry.

MickeyKnox commented on 2014-10-25 12:40 (UTC)

I've just installed avidemux-2.6 with aurget; that took some time to compile. After build was finished, it asked me for my sudo password, to install the package. I wasn't watching the build however, the password prompt timed out, sources got discarded, and i had to start all over again. Is this behaviour - uhh - intended?

brisbin33 commented on 2014-10-02 21:15 (UTC)

> However, as the AUR is no source code hosting platform, you should use the github tarballs instead for this package Agreed. I'm in the process of moving all my packages to this approach. It'll just take a little time...

carstene1ns commented on 2014-10-02 21:09 (UTC)

Skipping the hashes should only be used in packages with sources from vcs, not in fixed version packages. However, as the AUR is no source code hosting platform, you should use the github tarballs instead for this package: eg.

brisbin33 commented on 2014-10-02 20:31 (UTC)

Gently, I'm very familiar with git and tagging. I'm not as familiar with how we can automate packaging from this like you're insinuating. Specifically: In your PKGBUILD you're skipping md5sum and the source just lists the URL to the repo. Are you saying there's magic in makepkg that will use the generated pkgver (where `git describe` returns the most recent tag) to ensure the user builds from that specific tag and not current master? Is it considered safe to skip the md5 check in this scenario?

Gently commented on 2014-10-02 20:13 (UTC)

brisbin: I "tag" the git version. That way I can have what is called release versioning:

brisbin33 commented on 2014-09-23 15:48 (UTC)

bdunlap > This will be very helpful once I figure out if I can use this without having to edit each pkgbuild file man 5 aurgetrc

brisbin33 commented on 2014-09-23 15:48 (UTC)

Gently, I'm not sure I follow 100% the implications of using a PKGBUILD like that. It just looks like a -git PKGBUILD. Are you saying it can be used to build the stable release version *and* a -git version?

Gently commented on 2014-09-23 14:34 (UTC)

FYI, git support can be put right in the PKGBUILD... very easy:

bdunlap commented on 2014-09-07 02:48 (UTC)

This will be very helpful once I figure out if I can use this without having to edit each pkgbuild file, because I have no idea how to do that. I voted for it as many people use it and I can definitely see it's usefulness. Thank you, brisbin33 for creating and maintaining this.

brisbin33 commented on 2014-08-17 15:32 (UTC)

4.3.0 released with split package support Well done juengim!

brisbin33 commented on 2014-08-17 09:44 (UTC)

juengim, Thanks for the updated patch. It was actually still invalid as your email address was missing. I manually added it using the email from your profile here, hope that was OK. I've got it applied in a branch, but the existing test suite is failing so there may be a bug in your implementation. I'll have to spend some time sorting that out before I can release it. If anyone cares to try it out, it's the "slit-packages" branch on GitHub.

juengim commented on 2014-08-16 17:03 (UTC)

I never used git before. Is this what you need?

brisbin33 commented on 2014-08-16 14:19 (UTC)

juengim, by credit i mean attaching your email/author info for the commit. I could use `git am` to apply the patch with you as the author and myself signing it off. For that to work, your patch would've had to have author information though (and it doesn't seem to now). See Could you make a new patch by using `git format-patch`?

juengim commented on 2014-08-16 09:47 (UTC)

OK, thanks. I'm not sure what you have in mind in terms of credit. Personally, I'm not interested in any credit. Unfortunately I don't know how to do cram tests. I hope you can take care of that part.

brisbin33 commented on 2014-08-15 21:09 (UTC)

OK, I don't have a problem accepting a raw patch if you're not on GH -- I might need some pointers on ensuring you get credit for the change though. I think the color change is good, I'll take care of that. Also, by "test", I meant an actual cram test. If you can't figure out the way I'm doing testing though, I can probably take care of adding tests after I merge your change. Either way, I'll be able to revisit this over the weekend hopefully.

juengim commented on 2014-08-15 15:06 (UTC)

One more thing: I think this would be a better default value for $colorW: colorW="\e[0;1m" This is white+bold on a black background and black+bold on a white background. The current default is also white on a white background which isn't optimal: colorW="\e[1;37m"

juengim commented on 2014-08-15 14:45 (UTC)

brisbin33, thanks for the response. I'm not on github though and I'm not sure if I want to open an account just for this. Any chance you'd consider the patch anyway? I've also extended the patch a bit and added dependency handling for split packages. Here is the new version of the patch: If aurget adds a split package as a dependency for another package, the split package is now correctly installed as dependency (--asdeps). Here are some tests: Simple installation of a split package: aurget -S chromium-pepper-flash Installation of a split package as a dependency for another package (chromium-pepper-flash is the dependency): aurget -S freshplayerplugin --deps

brisbin33 commented on 2014-08-15 12:36 (UTC)

juengim, thanks for the patch -- would you mind submitting it as an actual PR on github? There I can review and merge while preserving credit to you more easily. Also, adding a test would greatly increase the chances of a quick merge.

juengim commented on 2014-08-15 08:18 (UTC)

Here is a patch for split package support:

FernandoBasso commented on 2014-07-25 10:11 (UTC)

That is great. Thanks.

brisbin33 commented on 2014-05-31 14:05 (UTC)

FYI bluestreak0, implemented both features. - Votes are now included in -Ssi output - All search results can be sorted by votes descending by passing --sort votes

brisbin33 commented on 2014-05-30 13:40 (UTC)

Thanks for the suggestions (and using/liking the tool). I'll add these on GitHub, but can't promise a timeline.

bluestreak0 commented on 2014-05-30 13:38 (UTC)

Feature request(s): 1. Showing number of votes for each package (when searching) 2. Sorting results by votes! Thanks, otherwise it's a great little app, I much prefer it to yaourt etc and use it all the time. Keep up the good work!

brisbin33 commented on 2014-03-21 14:48 (UTC)

Just realized, there's already --nodiscard. I'm going to keep aurget's simple behavior for now. For those that bump up against this issue, please either do $ PKGDEST="$PWD" aurget -Sb xxx Or $ aurget --nodiscard -Sb xxx Thanks

brisbin33 commented on 2014-03-14 14:12 (UTC)

blum, Default behavior is now to build the package in the source directory. I've made the decision to no longer actively override or extend how makepkg works, and that's makepkg's default behavior. Default behavior is also to discard sources after a successful run. This is a sane default in general, but a bit unfortunate for -Sb since the package might be in there! You can try a few things: - make sure your aurgetrc is at ~/.config/aurgetrc ($XDG_CONFIG_HOME) - set discard_source=false in aurgetrc - set PKGDEST to tell makepkg to put the package somewhere else $ PKGDEST="$PWD" aurget -Sb xxx The PKGDEST approach is pretty easy, but I would also consider the following changes to aurget's default behavior: - Add a --[no]keep commandline flag - Keep sources by default when -b is used

blum commented on 2014-03-14 12:01 (UTC)

Hmm.. I think I have a problem with the new verison. After $aurget -Sb xxxxx , the package is not in the current folder. Where is it?

brisbin33 commented on 2014-02-18 00:40 (UTC)

I love that this comes up every few months. Taurball is not a misspelling, it's a term coined by Xyne for AUR Tarballs which I use completely intentionally.

rh995 commented on 2014-02-15 04:25 (UTC)

I like the misspelling. It gives this amazing package some character.

SchrdngrsZombie commented on 2013-12-06 18:24 (UTC)

:: Retrieving taurball from AUR... ;)

brisbin33 commented on 2013-11-07 15:20 (UTC)

"because the search output gives me white package names on a white terminal background" krisz, in your case the "prescribed" fix would be to change $colorW in your config. But if you don't want color, you don't want color.

brisbin33 commented on 2013-11-07 15:05 (UTC)

That was probably an oversight, I'll update things when I get the chance. Thanks!

krisz commented on 2013-11-07 12:30 (UTC)

Would be nice to have the option listed in the manpage to permanently disable color output. Or is this option deprecated or broken? I use "disable_color='true'" because the search output gives me white package names on a white terminal background and I don't need colored output at all.

brisbin33 commented on 2013-08-23 16:54 (UTC)

Yes the config has moved. Place your customizations in ~/.config/aurgetrc. I've just pushed a new version which adds manpages. Please review them. man 1 aurget man 5 aurgetrc

phunni commented on 2013-08-04 17:45 (UTC)

In my /etc/aurgetrc I have the following: edit_pkgbuilds='never' I also have no idea where it's downloading and building to - it's as if it's using a different config? Has the config moved?

brisbin33 commented on 2013-07-27 21:58 (UTC)

phunni, The option is edit_pkgbuilds (with an s). If you're still having problems, please post a pastie of aurget running with --debug. Also, "Anyone jumping v3->4 should check their config against the example /usr/share/aurget/config. Yes, I should've put a message like that in the post_upgrade hook -- I'm sorry :("

phunni commented on 2013-07-27 19:16 (UTC)

For some reason, this now ignores my edit_pkgbuild="never" setting and always prompts me...

commented on 2013-06-15 19:34 (UTC)

It says ":: Retrieving taurball from AUR..." during any install. Shouldn't it be ":: Retrieving tarball from AUR..."?

commented on 2013-06-15 19:31 (UTC)

":: Retrieving taurball from AUR..." Shouldn't this letter ↑ be removed?─────────╯

commented on 2013-06-15 19:31 (UTC)

":: Retrieving taurball from AUR..." Shouldn't this letter ↑ be removed?───────────╯

brisbin33 commented on 2013-06-03 17:56 (UTC)

Hi pirateofms, From the README: > I want to control where the built package goes. > > Set PKGDEST either in makepkg.conf or as an environment variable. This is a makepkg feature, not aurget. Thanks

commented on 2013-06-03 17:52 (UTC)

Would it be possible to get an option to move completed package files to a directory to keep?

brisbin33 commented on 2013-05-27 18:18 (UTC)

neubauten84, aurget uses $EDITOR or $VISUAL, so just set one of those as nano.

neubauten84 commented on 2013-05-25 10:07 (UTC)

Is it possible to set 'nano' as prompt editor??

brisbin33 commented on 2013-05-03 17:27 (UTC)

Sorry about that hexist. Anyone jumping v3->4 should check their config against the example /usr/share/aurget/config. Yes, I should've put a message like that in the post_upgrade hook -- I'm sorry :(

commented on 2013-05-03 14:41 (UTC)

For anyone who runs into my cannot create `` directory, the problem was in an old ~/.config/aurgetrc , there was a line in there build_directory= commenting it out or setting it appropriately fixes the problem.

commented on 2013-05-03 14:26 (UTC)

This has been broken for me ever since I upgraded to 4.0.8-1, I keep getting mkdir: cannot create directory ‘’: No such file or directory error: unable to make build directory for any package I attempt to install. Has anyone else had this issue or know how to fix it?

SanskritFritz commented on 2013-04-25 11:34 (UTC)

Yes, bauerbill.conf contained this: (AUR tarball = taurball)

SanskritFritz commented on 2013-04-25 11:31 (UTC)

It's intentional pun, I think Xyne invented this expression.

fettouhi commented on 2013-04-25 10:44 (UTC)

Is this a spelling error or just a pun? Retrieving taurball from AUR...

brisbin33 commented on 2013-04-21 15:00 (UTC)

Whoops! Fixed in 4.0.1, thanks.

cleanrock commented on 2013-04-21 14:03 (UTC)

I get this when i start a terminal: bash: /etc/bash_completion.d/aurget: line 35: syntax error near unexpected token `return' bash: /etc/bash_completion.d/aurget: line 35: ` -h|--@(help|ignore) return 0 ;;'

brisbin33 commented on 2013-04-21 05:05 (UTC)

FYI v4 changes some things, please see the github README for details.

brisbin33 commented on 2013-04-07 17:56 (UTC)

matburt, is this on -Syu or -S anything? Can you attempt to install each package that -Syu is attempting to install separately and see if they all fail or just one? If so, please let me know the failing package.

brisbin33 commented on 2013-04-07 17:53 (UTC)

L8D is this with any command at all? Are there some more details you could provide?

commented on 2013-04-06 01:10 (UTC)

I keep getting: curl: (3) [globbing] error: bad range specification after pos 5[1-4] When I use aurget.

Det commented on 2013-04-05 09:46 (UTC)

Actually you'd be better off using the .pacnew from the new one (/etc/pacman.conf.pacnew).

commented on 2013-04-05 05:48 (UTC)

SOLVED! A friend helped me with this: it's seems that the last pacman does everything. It doesn't need to be synced first, so the 9-th line in the pacman.conf must be like this #SyncFirst = pacman and aurget it's working again. Also, the error messages from the pacman -Syu are gone.

commented on 2013-04-05 05:15 (UTC)

Hi, guys! Today, after the usual upgrades I've noticed that I can't use anymore "aurget -Su", I'm getting this message ":: Starting AUR upgrade... warning: config file /etc/pacman.conf, line 19: directive 'SyncFirst' in section 'options' not recognized. there is nothing to do" Any idea? Archlinux x86_64, Gnome desktop

commented on 2013-02-03 21:50 (UTC)

I actually just started seeing hgabreu's problem today too. aurget will fetch and build the package but fail to proceed to install it.

hgabreu commented on 2013-01-17 16:04 (UTC)

@brisbin33 it's working now. I have no idea why. Anyway, the first time I saw this error I was running a: $ aurget -Syu Later, I'm not completely sure if it was on all cases, but I think I was always installing multiple packages at once. Well, today I can't reproduce it anymore, no matter the scenario.

brisbin33 commented on 2013-01-17 14:46 (UTC)

hgabreu, That sounds bad -- I'll try to get some time this weekend to investigate. gdamjan, Set discard_sources=false in your config, everything will be left in the build_directory.

hgabreu commented on 2013-01-16 01:15 (UTC)

aurget is now giving me an error for every package. Even though it downloads and builds everything normally, right in the end it shows: :: Installing package... error: : package not found Then, I have to go to my $package_directory and `sudo pacman -U <package>` manually. Is this happening to anyone else?

gdamjan commented on 2012-12-21 02:55 (UTC)

Is there a way for aurget to cache the source downloads? I'm asking since: - AFAIK packages in AUR still don't support split packages - packages like uwsgi-* all get built from the same source but create different packages

Det commented on 2012-11-01 00:56 (UTC)

Now there's three wasted words.

brisbin33 commented on 2012-10-31 22:42 (UTC)

Hmm. So this seems to be a symptom of a bit of a design flaw that aurget has (and raury does not). Namely, it separates the build and install step (vs just using makepkg -i). This means it needs to find the built package (and therefore needs to know the real pkgext). A proper fix would be to re-architect aurget to use makepkg -i, a hacky fix could be to re-source the PKGBUILD before/after building just in case it influenced PKGEXT, though I'm not sure that's a Good Thing for a PKGBUILD to be doing... Either way, I won't be able to get to this for a little while. So... Pull Requests welcome?

Det commented on 2012-10-30 19:13 (UTC)

No, not really. Now it's only prioritizing makepkg.conf when before it didn't read the PKGBUILD at all (only unsetting it from makepkg.conf works).

brisbin33 commented on 2012-10-30 17:27 (UTC)

Det, please test with the latest version from git, and let me know if it's fixed. Thanks

brisbin33 commented on 2012-10-30 15:17 (UTC)

That's curious. I'd expect both broken or both to work. I'll take a look.

Det commented on 2012-10-30 15:13 (UTC)

Doesn't seem to be taking into account cases when the "PKGEXT" is set inside the PKGBUILD (eg. jre and google-earth). Raury works though but I hope you'll be updating this one as well. Doesn't require any ruby dependencies to say the least.

brisbin33 commented on 2012-10-18 22:52 (UTC)

Thanks Fernando! You should take a peak at raury too, it's a ruby-clone of aurget that runs much faster and should provide the same feature-set.

FernandoBasso commented on 2012-10-18 21:53 (UTC)

I love Aurget! :D

luolimao commented on 2012-10-17 20:05 (UTC)

Didn't know you had a github. Anyway, done.

brisbin33 commented on 2012-10-17 19:38 (UTC)

Would you mind opening a Pull Request on github with these fixes?

luolimao commented on 2012-10-17 19:21 (UTC)

Yes, the permissions are set to drwxr-xr-x (755) automatically for the parent directories, regardless of what comes after the -m option, or the current user mask.

brisbin33 commented on 2012-10-17 13:11 (UTC)

Cool, do happen to know: if I use -D -m644 (since that's the permissions the file must have) will intermediate directories correctly be set to 755? I believe that was the reason I separated things initially.

luolimao commented on 2012-10-17 02:02 (UTC)

Thanks for writing and packaging the aurget script! Btw, the mkdir lines are unnecessary; you can just change the install lines to install -Dm644 or install -Dm755 or whatever is needed (the -D option makes the parent directories automatically).

brisbin33 commented on 2012-10-10 22:04 (UTC)

curl is the new hotness anyway, but i just noticed i missed a spot when converting the wget calls over. i'll release a curl-only version next week.

karol_007 commented on 2012-10-10 21:54 (UTC)

That's because wget has recently been moved from 'base' group and [core] repo to [extra]:

adrianbs commented on 2012-10-10 21:48 (UTC)

I'm getting an error because I have no wget. I think it should be added as a dependency.

ska commented on 2012-09-12 23:57 (UTC)

Seems /usr/bin/aurget uses wget instead of curl in line 573: read -r Name Version URLPath < <(wget -q -O - "${aur_info}$(url_encode "$name")" | sed -e '/.*"Name":"\([^"]*\)".*"Version":"\([^"]*\)".*"URLPath":"\([^"]*\)".*/!d; s//\1 \2 \3/g') Maybe this could be replaced with curl or wget added as a dependency.

brisbin33 commented on 2012-05-23 01:33 (UTC)

Thanks idupree, aurget has an --mopt flag for passing arbitrary additional options to makepkg. You can also add it to makepkg_command in the config if you'd like it to be used always.

idupree commented on 2012-05-23 01:01 (UTC)

Aurget doesn't yet support a pacman configured to require package signatures; makepkg needs to be passed --sign in this case (and that's all that's needed, so I tweaked it locally that way). An aurget --sign flag would be the simplest fix, or more smarts would be even better. (Unless I missed something.)

wizetek commented on 2012-02-14 15:17 (UTC)

It was late and I didn't exercise my due diligence to investigate this before taking a shortcut and posting my comment here. Will do. Thanks.

brisbin33 commented on 2012-02-14 14:23 (UTC)

MajorTom, it's not a --deps problem. It's the exact same issue as asch is having: $ aurget -Sp obconf-git | grep ^name= name=obconf Please ask the obconf-git maintainer to not use "name" in the PKGBUILD.

wizetek commented on 2012-02-14 05:30 (UTC)

3.4.0-2 In certain cases, there are problems when passing the --deps argument. Part of the package name '-git' gets chopped off in the example below. $ aurget -S obconf-git searching AUR... Targets (1): obconf-git-20090208-1 Proceed with installation? [Y/n] n $ aurget -S --deps obconf-git resolving dependencies... searching AUR... error: obconf: package not found in AUR. $ aurget -S obconf-git --deps resolving dependencies... searching AUR... error: obconf: package not found in AUR.

brisbin33 commented on 2012-02-09 16:05 (UTC)

The PKGBUILD intruduces a name variable ("musicbranzngs") for its own use. So sourcing it overwrites the one I'm using and causes this behavior. "Do not introduce new variables into PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore (_), e.g. ..." Please comment on that packages page with an updated PKGBUILD which uses _python and _name instead; should install fine thereafter.

asch commented on 2012-02-09 15:56 (UTC)

When trying to install python2-musicbrainzngs it fails with no package message (musicbrainzngs not found, prefix python2 is lost by aurget).

karol_007 commented on 2012-01-21 18:27 (UTC)

Not sure what you mean: [karol@black ~]$ aurget -S aurget searching AUR... warning: aurget-3.4.0-2 is up to date -- reinstalling Targets (1): aurget-3.4.0-2 Proceed with installation? [Y/n]

zerox2a commented on 2012-01-21 18:23 (UTC)

Why doesn't aurget display a hint if a package is already installed or not? Would be nice to have such a feature

brisbin33 commented on 2011-11-14 14:16 (UTC)

There was a pull req recently on github to stop double edits of PKGBUILDs (once for resolving deps and once before building). I didn't realize there would be a problem since any changes made during the dep check edit are not saved. When I get some time I'll revert that change.

dapolinario commented on 2011-11-14 04:22 (UTC)

The package is not resolving dependencies added to the PKGBUILD, keeping the original file downloaded from AUR.

wizetek commented on 2011-11-14 00:55 (UTC)

Fixed. Many thanks, Pat.

wizetek commented on 2011-11-06 05:04 (UTC)

BASH autocompletion with aurget *as root* spits out a warning: # aurget -S anysearchstringerror: You must pass --asroot to allow running aurget as root (not recommended). I actually have alias aurget='aurget --asroot'. Do you think you anything can be done about that? Thanks.

zerox2a commented on 2011-09-21 09:40 (UTC)

Thank you very much for sorting the ouptu of aurget alphabetical now, good job! One more thing, Would it be possible to get a verbose command line option? I would like to see which packages are updated when doing aurget -Syu. Something like aurget --verbose -Syu or make this configurable through aurgetrc Regards

commented on 2011-09-18 16:00 (UTC)

Hi, I think ca-certificates is a dependency. Because it is an optional dependency for the wget, and aurget gets https download.

brisbin33 commented on 2011-08-23 13:53 (UTC)

I wonder if the JSON interface used to sort but now does not? I find it odd that this was never requested before...

zerox2a commented on 2011-08-23 10:45 (UTC)

Why does aurget not sort the output of "aurget -Ss foo" not alphabetical? I think this would be handy! Thanks for this great AUR helper!

brisbin33 commented on 2011-08-22 23:09 (UTC)

craziness. anyway, same bug different place... i'm not being DRY enough apparently. fixed in .13

karol_007 commented on 2011-08-22 20:23 (UTC)

And it somehow creates a file ... -rw-r--r-- 1 0 08-22 22:21 {"type":"error","results":"No.tar.gz

karol_007 commented on 2011-08-22 20:16 (UTC)

[karol@black test]$ aurget -S foobar searching AUR... Targets (1): {"type":"error","results":"No-results Proceed with installation? [Y/n] :: Retrieving source tarball from AUR... --2011-08-22 22:14:44-- http://aur.archlinux.orgfound%22%7D/ Resolving aur.archlinux.orgfound"}... failed: Name or service not known. wget: unable to resolve host address `aur.archlinux.orgfound"}' error: failed to retrieve aur sources A "package not found" would be nice.

wizetek commented on 2011-08-22 00:20 (UTC)

Indeed, fixed in 3.2.12. Thank you.

brisbin33 commented on 2011-08-21 17:28 (UTC)

Thanks for reporting. There have been some changes in the rpc interface recently (breaking a lot of helpers). Should be fixed with 3.2.12

wizetek commented on 2011-08-21 17:15 (UTC)

aurget 3.2.11-1 $ aurget -Syu warning: diffpac: local (20101219-1) is newer than aur (20100118-1) warning: firebrand: local (3.6-3) is newer than aur ({"type":"error","results":"No results found"}) warning: ttf-consolas: local (1-1) is newer than aur ({"type":"error","results":"No results found"}) warning: uswsusp: local (0.8-6) is newer than aur ({"type":"error","results":"No results found"}) warning: xf86miscproto: local (0.9.3-1) is newer than aur ({"type":"error","results":"No results found"}) warning: xorg-res-utils: local (1.0.3-3) is newer than aur ({"type":"error","results":"No results found"})

commented on 2011-07-11 19:16 (UTC)

Thanks alot, mate! Just tested and works perfectly now! I really appreciate your efforts and thanks again! CU, Martin.

brisbin33 commented on 2011-07-10 23:07 (UTC)

Fix pushed mhertz. FYI: I'm going to let it sit in git for a bit before updating the aur package.

commented on 2011-07-10 01:21 (UTC)

Thanks alot, mate; most appreciated! CU, Martin.

brisbin33 commented on 2011-07-10 01:15 (UTC)

Hmm, that should definitely work; probably a typo on my part. I'll see if I can figure it out and get in a fix in soon.

commented on 2011-07-10 01:10 (UTC)

You seriously rocks, brisbin! It works perfectly! Thank you so much for adding this nice new functionality! I tested with adding a simple textfile named ratpoison-git into /etc/customizepkg/, which adds the --without-xft build-option to ratpoison(cuts ram usage in half), and then runned './aurget -S --noedit ratpoison-git' from a git-clone of latest aurget, and everything works perfectly! Thanks again! Btw, if I could please ask you one more final thing, then I preffer to not touch the config file for aurget, and instead use aliases with the needed command-line args, but i'm having some difficulty with getting aurget to use /tmp for sources/packages and to leave the current working folder clean and empty after the aurget run... It works fine if I in the config define 'package_directory=/tmp' and 'build_directory=/tmp', but if the config is untouched, and I instead add the following extra args: --package_directory=/tmp and --build_directory=/tmp', then I still get the built package sitting in current directory after aurget operation? I e.g. ran: 'aurget -S --noedit --package_directory=/tmp --build_directory=/tmp ps_mem' and still afterwards got the ps_mem package tarball sitting in current working directory afterwards? Thanks in advance! Martin.

commented on 2011-07-10 01:07 (UTC)

You seriously rocks, brisbin! It works perfectly! Thank you so much for adding this nice new functionality! I tested with adding a simple textfile named ratpoison-git into /etc/customizepkg/, which adds the --without-xft build-option to ratpoison(cuts ram usage in half), and then runned './aurget -S --noedit ratpoison-git' from a git-clone of latest aurget, and everything works perfectly! Thanks again! Btw, if I could please ask you one more final thing, then I preffer to not touch the config file for aurget, and instead use aliases with the needed command-line args, but i'm having some difficulty with getting aurget to use /tmp for sources/packages and to leave the current working folder clean and empty after the aurget run... It works fine if I in the config define 'package_directory=/tmp' and 'build_directory=/tmp', but if the config is untouched, and I instead add the following extra args: --package_directory=/tmp and --build_directory=/tmp', then I still get the built package sitting in current directory after aurget operation? I e.g. ran: 'aurget -S --noedit --package_directory=/tmp --build_directory=/tmp ps_mem' and still afterwards got the ps_mem package tarball sitting in current working directory afterwards? Thanks in advance! Martin.

brisbin33 commented on 2011-07-09 22:20 (UTC)

I've just committed a change to github which tries to accomplish this. I don't use customizepkg so I didn't test, can you? I did verify that normal building etc still works.

commented on 2011-07-09 03:34 (UTC)

Hi brisbin! Wow, I _love_ your bash_completion script! That seriously rocks to be able to complete aur packages, so I don't need to use -Ss first! Anyway, could I possibly get you to consider adding customizepkg as an optdepends to aurget, like yaourt has? This is so that we don't need to edit the pkgbuilds upon each upgrade/install, and instead have the pkgbuilds auto-patched upon install with e.g. custom ./configure options, or add/remove deps, or include patches etc. It could e.g. be a simple: " [[ -f "/etc/customizepkg.d/$1" ]] && customizepkg --modify " one-line addition to your script, just after the package-tarball is unpacked... Just a thought! Anyway, thanks again for your nice script! Martin.

brisbin33 commented on 2011-06-16 18:45 (UTC)

@archman Up until recently, a renaming was simply deleting the existing package and posting a new one. Under that process, my (or any other) helper has absolutely no way to detect a name change. There was some discussion on the aur-general mailing list recently about providing some level of built in support for renaming a package. If something along these lines were implemented, and if that link from new to old were persisted in the AUR's internal DB, and if that link were exposed in the rpc interface, only then could I add a feature like this. I'm probably not going to follow the ML discussion closely, but if you did, and let me know when/if something was implemented (or if it has been already), I'd be more inclined to look into adding this feature. Feel free to open an issue on github when you think the foundation is in place for something like this to be possible.

archman commented on 2011-06-15 20:15 (UTC)

Can this AUR helper notify the user (upon using 'aurget -Syu') when some AUR package changes its name? Can this feature be implemented, maybe?

commented on 2011-03-25 12:40 (UTC)

Nice tool but it should display the package name when it asks if we want to edit the PKGBUILD!

atomopawn commented on 2011-03-21 01:52 (UTC)

This is an excellent tool. Very well done!

lucak3 commented on 2011-03-12 23:18 (UTC)

It resolves deps now (again), many thanks to you and this good tool :)

brisbin33 commented on 2011-03-12 19:36 (UTC)

Heh, sorry; my fault all around. Please try again with 3.2.7. I successfully got passed the quad dep, but can't fully test a peazip-qt install due to architecture...

lucak3 commented on 2011-03-12 19:19 (UTC)

Yes, i did update, even pacman says so, but aurget -v says 3.2.5. BTW, i'm sorry, i didn't specify, it's peazip-qt, which has quad in it's depends array.

brisbin33 commented on 2011-03-12 17:51 (UTC)

Did you upgrade to aurget 3.2.6? What package are you really trying to install? Just 'peazip' doesn't exist and none of the peazip-* packages want to pull in quad as a dep for me. I just successfully installed quad by itself, so I know that should workd.

lucak3 commented on 2011-03-12 17:29 (UTC)

Now it says Installing missing dependencies... error: 'quad': could not find or read package

brisbin33 commented on 2011-03-12 15:00 (UTC)

Fixed committed, pushed, and uploaded. Please let me know if quad still doesn't work.

brisbin33 commented on 2011-03-12 14:46 (UTC)

I guess this serves as notice to everyone. There's a change going on in the AUR where PKGBUILD urls are going from the usual:$package/$package/PKGBUILD to the simpler but different$package/PKGBUILD I would obviously fix for this change, but it's only been applied to packages uploaded since the decision to make the change. I haven't heard much on the matter, what the plan is, or if it'll forever be in this half-and-half state. Currently, there is only a TODO: in aurget and packages (like quad) with the new url scheme just won't be found. Ideas (and patches) welcome. I'll be hacking on it today. Sorry for the inconvenience.

lucak3 commented on 2011-03-12 08:16 (UTC)

I have a problem with 'aurget -S peazip': it seems it can't find 'quad' which is a dependency, even if it's written correctly AFAICS.

commented on 2011-02-08 03:06 (UTC)

Oops, forgot to set the reset color setting. My mistake. t.t;

brisbin33 commented on 2011-02-06 14:46 (UTC)

I'm afraid I can't reproduce this. Could you give a little more info? What specific commands give you this behavior? What are your color setups? Did you forget to set the "reset" color (nocolor)?

commented on 2011-02-06 04:48 (UTC)

The colors 'leak.' The last color used by aurget is stuck.

brisbin33 commented on 2010-12-30 08:49 (UTC)

Quite normal; --noconfirm means "auto-answer Yes to all prompts". So in case of build error, aurget asks "foo failed to build, discard sources?" and you [auto-]answer Yes.

lucak3 commented on 2010-12-28 12:57 (UTC)

Is it normal that with "don't discard sources" true and the --noconfirm option passed to cmdline, sources get discarded nonetheless in case of errors?

brisbin33 commented on 2010-11-22 14:54 (UTC)

Hmm. Please use a pasting service to link me the contents of debug.log created using the following command: bash -x aurget --rebuild --edit --nodeps -S aurget 2>debug.log Just to the point of editing the pkgbuild, then you can abort before building. Thanks.

Rulatir commented on 2010-11-22 07:26 (UTC)

Always uses vi for PKGBUILD editing, no way to get it to use mcedit. I have both set the EDITOR variable and overriden pkgbuild_editor in /usr/bin/aurget, still no joy.

brisbin33 commented on 2010-10-17 15:57 (UTC)

not sure what happened, i think it's fixed now though. putting aurget in the tarball makes sense, i'll set that up soon too.

gdamjan commented on 2010-10-16 21:40 (UTC)

how about putting the aurget script itself in the package source?

widowild commented on 2010-10-16 20:56 (UTC)

pls update a md5sum

gborzi commented on 2010-10-16 20:42 (UTC)

Hi brisbin33, points to the previous version of aurget, and md5sum are repeated in PKGBUILD.

brisbin33 commented on 2010-09-02 21:08 (UTC)

Sorry about, I moved yesterday and didn't get internet back until now. Good news is an ISP change means I don't need the :8080 everywhere anymore! I'll be updating links as I go for the next little while.

gborzi commented on 2010-09-02 10:48 (UTC)

The site is down!

commented on 2010-08-11 20:56 (UTC)

Just upgraded, it seems to be working for me. The "prompt to edit?" option is exactly what I was looking for. Thanks.

brisbin33 commented on 2010-08-10 22:18 (UTC)

I've just uploaded 3.0.8 with 3 major changes. I'm a bit nervous b/c I haven't done much testing, but it's been sitting in my ~/.bin for quite some time and I need to push it. * a bash completion file * remove_makedepends option * edit_pkgbuilds option I'm sorry if this causes breakages.

brisbin33 commented on 2010-08-10 20:58 (UTC)

I think I see what you mean; I was never bothered b/c I never edit anything :D. Maybe changing that option to 'edit PKGBUILDS? (never|always|prompt)' from the current 'prompt to edit? (true|false)' would work?

commented on 2010-08-10 20:50 (UTC)

Can we have an option in the config file so that we can control the default setting for "check PKGBUILD before installing"? Having it as 'y' can be annoying sometimes. Other than that, love this tool.

brisbin33 commented on 2010-08-08 21:42 (UTC)

sorry about that. had a power outage the day i left for vacation, couldn't reboot till now; should be all set.

commented on 2010-08-07 17:19 (UTC)

The address is not active or the server has been down for a few days now.

brisbin33 commented on 2010-06-19 17:42 (UTC)

very nice, thanks. i'll combine this with my existing clean_string() function which does 1 or 2 common hex conversions for the rpc search url. also, hexdump is owned by util-linux-ng which is part of [base] which is nice.

lrm commented on 2010-06-19 17:23 (UTC)

Right now aurget doesn't url encode the URL before installing a package. Normally this isn't a problem, but while trying to fetch gdb-c++-pretty-svn, it became an issue. The two +'s in the package name need to be encoded with %2b. The patch at fixes this by adding a quick url_encode function that depends only on hexdump and awk. If hexdump isn't present on the system, it will silently proceed without encoding the URL.

brisbin33 commented on 2010-06-16 14:54 (UTC)

by the way. version="3.0.0-1" is populated with the aurget version that generated the config. it's a simple way for me to know if someone's using updated aurget with an old config (i just check [[ -z "$version" ]] after sourcing) and nothing else.

brisbin33 commented on 2010-06-16 14:51 (UTC)

just a mistake on my part, updated. also realized i forgot to remove the curl dep that's no longer needed.

wizetek commented on 2010-06-16 00:03 (UTC)

OK, I wasn't expecting anything major but decided to let aurget regenerate the config file: # aurget 2.0 config file, generated ... Did you intentionally leave it at 2.0 as in "config format v2.0"? Just checking. EDIT: just noticed version="3.0.0-1" at the bottom.

brisbin33 commented on 2010-06-15 17:36 (UTC)

Updated. 3.0 is nothing special, i just messed up my versioning last time around and would like to start fresh at 3.0.0 :).

brisbin33 commented on 2010-06-14 13:47 (UTC)

Tom, I've made a simple fix for that use case and will upload the new version soon. Thanks.

wizetek commented on 2010-06-12 19:19 (UTC)

Hey Pat. It's me again. On one of my boxes, until recently, I had no ~/.config directory. I was using ~/.aurgetrc for aurget settings. I happened to install a package which needed the .config dir and when I ran aurget it failed to read its settings file. I ended up moving ~/.aurgetrc to ~/.config/aurgetrc. Can you please make aurget look for ~/.aurgetrc first and then, if that fails, look for ~/.config/aurgetrc (full path, not just the existence of ~/.config dir)? Thanks.

brisbin33 commented on 2010-06-06 00:35 (UTC)

yes, this is intentional and the behavior can be changed. i might make it a config option. let me think about it a bit... if you'd like to edit the script source yourself, take a look at builderror() (line 35) and just comment the last three statements in that function.

wizetek commented on 2010-06-05 23:49 (UTC)

When installing multiple packages, a single package failure prevents others from being retrieved and build. Example: # aurget -S xbmc-skin-mc360-svn xbmc-skin-mediastream-redux xbmc-skin-mediastream-svn xbmc-skin-minimeedia xbmc-skin-rapier xbmc-skin-serenity-svn xbmc-skin-transparency-svn xbmc-skin-vinci xbmc-skin-vision2-svn searching AUR... Targets (9): xbmc-skin-mc360-svn-2113-1 xbmc-skin-mediastream-redux-1.0-1 xbmc-skin-mediastream-svn-2515-1 xbmc-skin-minimeedia-0.95-1 xbmc-skin-rapier-3.06-6 xbmc-skin-serenity-svn-28-3 xbmc-skin-transparency-svn-393-1 xbmc-skin-vinci-20080911-1 xbmc-skin-vision2-svn-1692-1 Proceed with installation? [Y/n] :: Retrieving source tarball from AUR... . . . ==> Starting build()... svn: Repository moved temporarily to ''; please relocate /home/xbmc/builds/xbmc-skin-mc360-svn/PKGBUILD: line 23: cd: MC360: No such file or directory sh: No such file or directory /home/xbmc/builds/xbmc-skin-mc360-svn/PKGBUILD: line 26: cd: BUILD: No such file or directory cp: cannot stat `MC360': No such file or directory ==> ERROR: Build Failed. Aborting... error: xbmc-skin-mc360-svn failed while building, remove source files from /home/xbmc/builds/xbmc-skin-mc360-svn? [Y/n] ...and we're back to shell. It would be nice to continue with the next package build after this error. Can it be done? Thanks.

brisbin33 commented on 2010-05-12 13:34 (UTC)

I've implemented the gborzi change. those of you who don't use SRCDEST shouldn't notice anything different. in the default config, build_directory has now replaced source_directory; here is the snippet from the updated config: # # where to download source files and do the actual building. aurget # will create subdirectories named after the packages being built. # leave blank to the use current working directory. this replaces the # deprecated option source_directory. ### build_directory= don't worry; if you forget to convert your config to use build_directory, aurget will look for and use the deprecated source_directory setting. thanks.

brisbin33 commented on 2010-05-09 20:51 (UTC)

the intent wasn't to keep them in two different places. it was just freedom of config. if you're like me, and never used a PKGDEST (and only use aurget to build packages), then you can just set it in aurgetrc. otherwise, just leave it blank and it will inherit PKGDEST from makepkg.conf (or fall back on ./). i think that pretty much satisfies every use case (and most importantly, my own :)).

gborzi commented on 2010-05-09 20:44 (UTC)

It makes sense to me, including using build_directory instead of source_directory. I'd also say that package_directory doesn't look useful to me. Why keep aurget built packages in a different directory from makepkg built package?

brisbin33 commented on 2010-05-09 20:19 (UTC)

Ah, that clears it up. Now I see that it doesn't make sense to have aurget override SRCDEST (it doesn't even need to be aware of it). I'm thinking I'm going to implement your fix exactly, plus a minor change to the default config. I'll rename source_directory to build_directory as that makes more sense (the deprecated source_directory can still be used if users haven't changed their configs yet...) and add a comment that you should set SRCDEST in makepkg.conf if that's the functionality you're looking for. I believe this will get the behavior users like you need/expect w/o effecting anyone else. Let me know if this doesn't make sense. I'll be testing with my ~/.bin version for a bit, then I'll update here.

gborzi commented on 2010-05-09 19:41 (UTC)

I have the following settings: makepkg.conf PKGDEST=/home/gborzi/store/personal SRCDEST=/home/gborzi/store/sources ~/.config/aurgetrc package_directory= source_directory=/home/gborzi/store/lab/aurbuild discard_sources=false (generally I set this to true, but modified to false for the test) doing "aurget -Sb aurget" I get ~/store/sources/aurget ~/store/personal/aurget-2.4-1-any.pkg.tar.xz ~/store/lab/aurbuild/aurget/{aurget.install,pkg,PKGBUILD,src} that is to say, PKGDEST is the one given in makepkg.conf (and unchanged in aurgetrc), SRCDEST is the one given in makepkg.conf because I removed SRCDEST="$_srcdir" from line 434, build directory is the "source_directory" (given in aurgetrc) followed by package name. Feel free to ask for more test, this package is very useful to me and I'm happy to help.

gborzi commented on 2010-05-09 19:23 (UTC)

I have the following settings: makepkg.conf PKGDEST=/home/gborzi/store/personal SRCDEST=/home/gborzi/store/sources ~/.config/aurgetrc package_directory= source_directory=/home/gborzi/store/lab/aurbuild discard_sources=false (generally I set this to true, but modified to false for the test) doing "aurget -Sb aurget" I get ~/store/sources/aurget ~/store/personal/aurget-2.4-1-any.pkg.tar.xz ~/store/lab/aurbuild/aurget/{aurget.install,pkg,PKGBUILD,src} that is to say, PKGDEST is the one given in makepkg.conf (and unchanged in aurgetrc), SRCDEST is the one given in makepkg.conf because I removed SRCDEST="$_srcdir" from line 434, build directory is the "source_directory" (given in aurgetrc) followed by package name. Feel free to ask for more test, this package is very useful to me and I'm happy to help.

brisbin33 commented on 2010-05-09 18:56 (UTC)

Yeah, it was just a typo in the message. So, the build still happens in the build directory, and you get src and pkg folders there; it's just that that src folder is cached in $SRCDEST to be shared/reused right? How does your $SRCDEST look after building multiple packages? $SRCDEST/src/{foo,bar,baz} or $SRCDEST/{foo,bar,baz}? I'll try and continue testing and get this fixed soon. Sorry to pull that out from under you.

gborzi commented on 2010-05-09 18:18 (UTC)

I have SRCDEST=/home/gborzi/store/sources in makepkg.conf and it works, that is to say makepkg downloads the sources in the given directory. You wrote that you have SCRCDEST=/home/patrick/Sources with too many 'C' in the variable name, is it a typo in the message or a typo in makepkg.conf?

brisbin33 commented on 2010-05-09 17:25 (UTC)

gborzi, thank you for the comment; I know what you mean. In testing, I couldn't really follow how SRCDEST is to be used. If I put SCRCDEST=/home/patrick/Sources in makepkg.conf, then I manually build a package with makepkg, when I'm done I've got nothing in ~/Sources. I have in stead the usual ./{src,pkg} in the build directory as if i hadn't defined SRCDEST at all. Am I doing something wrong? In aurget, I artificially change SRCDEST to the $srcdir/$name where $srcdir comes from makepkg.conf (in your case) or aurgetrc (in my case) and name is the currently being built package. I thought this mimicked the default makepkg behavior and was really only added so that running makepkg -e (reuse sources) in an aurget process would work. I've been pretty pleased with the result myself; neatly saved sources in ~/Sources/foo where foo is the package. This seems to come from the simple fact that aurget cd's to $srcdir before extracting/building and not any SRCDEST setting... Based on your comment, I can see how this isn't entirely correct from a repsect-makepkg.conf standpoint, but since I can't get makepkg to do anything with SRCDEST (other than fail on -e if it's not set right...), I was (and am) unable to do proper testing. How should it work?

gborzi commented on 2010-05-09 16:16 (UTC)

Hi brisbin33, there is an annoying behaviour in aurget 2.x: it doesn't save anymore the sources in SRCDEST (as specified in makepkg.conf). It's annoying to me because I have more than one computer so I prefer to share the source. I solved this problem by removing SRCDEST="$_srcdir" from line 434. Is it a bug or an intended behaviour?

wizetek commented on 2010-05-06 00:34 (UTC)

Good move with the change of parameters to mimic pacman in aurget 2.x. Thank you once again.

brisbin33 commented on 2010-04-29 19:18 (UTC)

Ah, damn typos! Thanks for letting me know, i'll get a new version out probably tonight.

gborzi commented on 2010-04-29 18:44 (UTC)

Hi brisbin33, there is a small bug in aurget 2.0. The variable ignore_packages in aurgetrc is not used in the script, it checks against a variable named ignore_package (without the final s). Besides this, it's wonderful.

brisbin33 commented on 2010-04-21 13:41 (UTC)

*Fair Warning* -- I'm currently testing aurget 2.0 which boasts faster searches/dependency checking, the ability to save/reuse sources, as well as overall cleaner code. However, this new version also comes with a completely different config file as well as completely different runtime flags. This package will be getting the upgrade soon, so watch out. If your interested in trying the new version now: If you want to keep the 1.x version forever: Thanks, Pat

brisbin33 commented on 2010-04-10 21:52 (UTC)

yes, that would solve it. i chose to do the following instead: -- touch "$WD/results.lst" ++ echo > "$WD/results.lst" this clears old results before running any search. originally i had never intended to run multiple searches back to back... thus the bug. you're right though s/>>/>/g is cleaner... don't remember why i had it appending to begin with...

commented on 2010-04-10 21:50 (UTC)

Ok... I'm not quite confident with bash but looks like this helps (patch is for 1.5-3) @@ -633,7 +633,7 @@ # package name has to match for info type search [ "$MODE" = 'info' ] && GREP="$term" - curl -s "$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 >> "$WD/results.lst" + curl -s "$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 > "$WD/results.lst" # no results

brisbin33 commented on 2010-04-10 21:49 (UTC)

thanks for the headsup orgronom. there was a bug in search() where it accumulated results rather than clearing them b/w searches (i.e. for each argument returned as out of date), this has been fixed. everyone, be advised that -qu and -su are /searches/ based on the list of out of date packages so they will return more than just the packages as results. this is probably not useful but it does make sense given the way the options work (it respects $MODE completely while acting). i did test that -uI works as expected since -I returns exact matches only. i may adjust -s and -q to operate differently (i.e. exact matches) if used in correlation with -u but that's not high on my to-do list right now...

commented on 2010-04-10 21:48 (UTC)

Ok... I'm not quite confident with bash but looks like this helps (patch is for 1.5-3) @@ -633,7 +633,7 @@ # package name has to match for info type search [ "$MODE" = 'info' ] && GREP="$term" - curl -s "$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 >> "$WD/results.lst" + curl -s "$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 > "$WD/results.lst" # no results

commented on 2010-04-10 14:36 (UTC)

Upgrade (-u) issue: While the install, build, download modes are fine I find the behaviour of quiet, info modes a little odd, i.e. I expected, that aurget -uq just prints the names of the packages from aur that needs to be upgraded, and aurget -uI prints also their info, but they are not. There is a bug in function search, that make the output repeat itself several times.

gborzi commented on 2010-03-27 18:38 (UTC)

Tried it and worked fine. I don't have a ~/.makepkg.conf, just /etc/makepkg.conf. BTW find <dir> -name supports the regexp with square brackets [].

brisbin33 commented on 2010-03-27 14:44 (UTC)

Yeah, i saw this coming but was just being lazy about fixing it... i'm also not sure if find -name supports the [xz] regexism there. either way, i'm sourcing makepkg.conf anyway so i just used $PKGEXT directly. now any extension should work. i tested myself using a ~/.makepkg.conf and an /etc/makepkg.conf with the xz extension specified. let me know if it's not working for you. thanks.

gborzi commented on 2010-03-27 02:03 (UTC)

There is a bug in the script caused by the recent switch to xz compression. If a user configured makepkg to use xz compression (like I did) the script fails with the error message cp: cannot stat `': No such file or directory error: codecs: failed saving package. Note: source files may still be in /tmp/aurget I think the problem is at line 952 of the script, i.e. PKG=$(find "$WD/$PACK" -name "$PACK-*pkg.tar.gz") which should read PKG=$(find "$WD/$PACK" -name "$PACK-*pkg.tar.[gx]z")