Arch Linux

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.

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 http://aur.pastebin.com/9Nd5kJ3p 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.

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.

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

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.

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 :).

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

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.

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.

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 'http://sourceforge.net/apps/trac/sourceforge/wiki/Subversion'; please relocate
/home/xbmc/builds/xbmc-skin-mc360-svn/PKGBUILD: line 23: cd: MC360: No such file or directory
sh: Build.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.

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.

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 :)).

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?

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.

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.

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.

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.

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?

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?

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?

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

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

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.

*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: http://pbrisbin.com:8080/bin/aurget

If you want to keep the 1.x version forever: http://pbrisbin.com:8080/shared/aurget_1.5-6

Thanks,
Pat

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...

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 "http://aur.archlinux.org/rpc.php?type=search&arg=$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 >> "$WD/results.lst"
+ curl -s "http://aur.archlinux.org/rpc.php?type=search&arg=$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 > "$WD/results.lst"

# no results

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...

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 "http://aur.archlinux.org/rpc.php?type=search&arg=$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 >> "$WD/results.lst"
+ curl -s "http://aur.archlinux.org/rpc.php?type=search&arg=$(clean_string "$term")" | sed 's/{/\n/g;s/}//g' | grep -F "\"$GREP\"" | sort -t ':' -k 3.2 > "$WD/results.lst"

# no results

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.

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 [].

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.

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")