Arch Linux User Repository

Can anyone help me out? I have tried on both a 64bit and a 32bit Arch install, both with AUR and with the Steam (for Linux) version - and in neither case I can hear any sound. Which is like, *huge* for this game. Anyone here with the same problem? Any idea for a fix?

The dependency list should include lib32-glu as well.

@ejona86: Ah, I suppose makepkg's error is more relevant only when manually downloading the PKGBUILD and building yourself (eg. without packer). I understand that you need to source a PKGBUILD in order to get things set up, my point was that you should avoid any functions defined by makepkg (like warning) unless makepkg was actually the one sourcing it. Maybe something like: if [ $(basename $0) = "makepkg" -a ! -f "${startdir}/${_gamepkg}" ]; then Anyway, defining nop functions in packer is the same idea I had the other day. I don't really care for it, but it works. Oh well. :)

>>> ~ cower -dd swordandsworcery :: swordandsworcery downloaded to /home/zekesulastin/aur :: lib32-curl downloaded to /home/zekesulastin/aur warning: lib32-libssh2 is available in multilib Seemed to pick up the x86_64 bit for me.

@gavinhungry, np. The problem with that error is that it doesn't say where the source package was expected. So when people build with yaourt, packer, etc, they simply have to know to put the file in /tmp/yaourt-tmp-$USERNAME/aur-swordandsworcery/, /tmp/packerbuild-$UID/swordandsworcery/swordandsworcery/, etc. Nowhere in the error does it say the folder it was building in. Concerning execution of PKGBUILDs: you _must_ run a PKGBUILD, otherwise setting dependencies for i686 vs x86-64 and the like don't get processed correctly. This is my issue with cower -- it gets dependencies wrong for i686 vs x86-64 since it tries not to execute the script. It sucks, but that is simply a requirement for the PKGBUILD format as it stands today. There are other things that will break if you don't execute the script, but that is the most obvious example to me. I think it would be reasonable to file a bug against packer, suggesting it defines warning, error, etc. as no-ops before determining dependencies.

@ejona86: Sorry, I should have been more specific. No, nothing is actually *breaking* with packer, and I agree the warning is useful, but not really any more useful than the error that makepkg throws up by default for any other missing file. It does seem to me that one should be able to source an arbitrary PKGBUILD without anything actually being exectuted (other than variables being set and functions defined). What's wrong with makepkg's: ==> ERROR: swordandsworcery_1.02.tar.gz was not found in the build directory and is not a URL. Especially considering you have "(game purchased separately)" in the description.

@gavinhungry. Hmm... build() is too late, because build() happens after "Retrieving Sources..." (which the message is suppose to help with). It doesn't appear that the test is bad for packer, but instead it is the usage of the warning function; it yells about warning. That doesn't appear to be fatal though as everything seems to build correctly. I do think the warning is useful, since people do seem to have trouble figuring out where to copy the swordandsworcery binary. If packer actually failed, then I would be more concerned.

The if test for ${startdir}/${_gamepkg} (lines 26-30) is bad for AUR helpers (such as packer) when parsing the PKGBUILD. Can that be put inside build()?

http://ix.io/2Oq this will automagically download the tarball too