Package Details: worldofgoo 1.41-6

Git Clone URL: (read-only)
Package Base: worldofgoo
Description: A physics based puzzle/construction game (requires copy of the full game).
Upstream URL:
Licenses: custom
Submitter: None
Maintainer: symen
Last Packager: symen
Votes: 107
Popularity: 0.156372
First Submitted: 2009-02-13 19:44
Last Updated: 2015-06-08 20:15

Dependencies (4)

Required by (1)

Sources (2)

Latest Comments

icemodding commented on 2016-01-07 06:35

-> Descargando WorldOfGooSetup.1.41.tar.gz...
Could not find hib://WorldOfGooSetup.1.41.tar.gz. Manually download it to "$(pwd)", or set up a hib:// DLAGENT in /etc/makepkg.conf.; exit 1
-> worldofgoo.desktop ha sido encontrado
==> Validando las fuentes con md5sums...
WorldOfGooSetup.1.41.tar.gz ... NO ENCONTRADO
worldofgoo.desktop ... Aprobado
==> ERROR: ¡Uno o más archivos no superaron el control de validación!
==> ERROR: Makepkg no ha podido compilar worldofgoo.
==> ¿Reiniciar la compilación de worldofgoo? [s/N]

it does not work :(

ArnaudNux commented on 2015-05-08 01:08

==> Validation des fichiers sources avec md5sums...
WorldOfGooSetup.1.41.tar.gz ... INTROUVABLE
worldofgoo.desktop ... Réussite
==> ERREUR : Un ou plusieurs fichiers sont invalides !
==> ERREUR: Makepkg n'a pas pu construire worldofgoo.
==> Relancer la compilation de worldofgoo ? [o/N]

rasr11 commented on 2015-03-19 15:09

Unable to download source :
-> Downloading WorldOfGooSetup.1.41.tar.gz...
Could not find hib://WorldOfGooSetup.1.41.tar.gz. Manually download it to "$(pwd)", or set up a hib:// DLAGENT in /etc/makepkg.conf.; exit 1

trya commented on 2013-07-15 16:15


C5OK5Y commented on 2013-07-15 09:00

@trya: I would gladly accept your offer.

And regarding local:// vs hib:// - I presume that the current usage of local:// is to hint the person, who is building the package, to place the World of Goo source file into $srcdir. The hib:// approach keeps such functionality for people who haven't defined a custom value for hib::// in /etc/makepkg.conf. This (along with the reason smls pointed out) eliminates any reason to use local:// instead or together with hib://.

smls commented on 2013-07-15 07:31


Update: Actually, when you buy the game directly from it still goes through the Humble Store, so I think hib:// should cover that as well.
(Of course humble:// would be a more appropriate/inclusive name for it, but everyone is already using hib:// so I'd say let's stick with it.)

smls commented on 2013-07-15 07:09

Regarding local:// vs. hib//, I think it's possible to specify alternatives like so:


But I haven't tested it.
If it works (i.e. first try the hib dlagent if any, if it fails use local), that would be the ideal solution imo.

smls commented on 2013-07-15 07:04

You don't have to wait for a new maintainer to volunteer, before disowning a package.
Simply disown as soon as you're not interested in the package anymore, or as soon as you know you're not gonna put in the work to maintain/improve it anymore.
Then new maintainers can just pick them up (otherwise they wouldn't even know that it's available)...

(For what it's worth, I'd be willing to maintain World of Goo and Braid myself, I love both games and still play them from time to time.)

trya commented on 2013-07-15 05:16

@C5OK5Y: I'm still not too keen on doing it, because World of Goo is not specifically distributed through the HIB. Nevertheless, I'd gladly let you maintain the PKGBUILD if you want to (Braid in the same case, I'd like to disown all my PKGBUILDs of commercial games).

C5OK5Y commented on 2013-07-12 18:17

@trya: Have you considered using the hib::// DLAGENT instead of local://? It greatly simplifies fetching of HB source files. Examples of configuring the hib::// DLAGENT from the user side are described here[1] quite thoroughly.


trya commented on 2013-02-20 12:48

@Kyrias: why would you need a 32-bit library for a game which has a 64-bit executable?

Kyrias commented on 2013-02-20 11:34

Should add that you need lib32-sdl_mixer from AUR if you're on 64-bit to post_install()

trya commented on 2013-01-03 10:59

I must admit the error message from makepkg can be very misleading because the PKGBUILD contains a unusual download agent. I didn't remember I could mess with pacman and makepkg variables from the PKGBUILD, so what I'll do for this sort of package is to add a "local" download agent directly into the PKGBUILD. Now, makepkg should behave as expected and issue a "NOT FOUND" error if the user doesn't provide the local sources.

PKGBUILD updated.

danbruegge commented on 2012-11-16 18:53

@trya, thx!

smls commented on 2012-08-14 18:01

@trya: I've handled this in my newly created own PKGBUILDs, by putting that logic into a separate Bash function. This way build() stays clean, and the functionality can easily be copied from one PKGBUILD to another. (See e.g.

However, I would much prefer if makepkg could natively handle this using a special SOURCE protocol like you use.
Although I would call it local:// rather than file://, to make it clear that it does *not* specify an arbitrary filesystem path, but rather is a generic way for the PKGBUILD to say "I need this file provided locally by the user". How the user provides it, should not be any of the PKGBUILD's concern - it would be an implementation detail of makepkg or the AUR helper.

Makepkg / the AUR helper could give the user the choice to either manually copy the file into the PKGBUILD dir, or set a $LOCAL_PACKAGE_SOURCES environment variable (like I implemented in my above mentioned Bash function), or even interactively query the user for the file. Then every user can choose how they want to provide such files, while PKGBUILD authors would not need to care about any of this.

trya commented on 2012-08-14 13:42

@smls: it's a workaround after all. I found it elegant at the time because, compared to the previous version of the PKGBUILD, it permitted me to greatly simplify the build() function. I don't know if there's a token for makepkg in order to exclude a file from the source tarball, I ought to find if it's possible and make a request eventually.


smls commented on 2012-08-14 12:36

@trya: Yes, I did realize from looking at the PKGBUILD that I would need to place the game archive in the PKGBUILD dir, but when I was confronted by this error message that *didn't* complain about not finding the file, but instead about not even knowing the protocol, I didn't even try any further. I assumed it was something that maybe worked with older makepkg versions but not anymore, or only with certain AUR helpers, and hence needed fixing.
I undestand your comments below now, although I guess I disagree about the usage of the term "elegant" for a solution that confronts the user with a completely misleading error message.
Don't get me wrong, I too think that the solution *would* be really elegant - if makepkg would explicitly support it.

trya commented on 2012-08-03 09:49

@smls: did you read the PKGBUILD? Did you read the discussion? You have to put the game tarball in the PKGBUILD directory.

smls commented on 2012-08-03 06:33

Installation fails with
"==> ERROR: There is no agent set up to handle file URLs. Check /etc/makepkg.conf."

trya commented on 2012-02-02 12:43

@Kppqju77: I don't the idea that much. Compare this PKGBUILD with those handling the Humble Bundle keys, you'll probably understand. Then, I'd like to prevent HB servers from clogging. One download is enough, make copies or links if necessary.

Kppqju77 commented on 2012-02-02 08:25

Can you do an installer with the _humblebundleandroidkey defined to grab it on humble bundle website (like bittriprunner,jamestown,cogs... with _humblebundle4key) ?

swiftgeek commented on 2011-12-12 08:21

Please disable compression of the package in the next release...

trya commented on 2011-10-29 09:43

Found an elegant solution to circumvent the "makepkg --source" issue by using an uncommon protocol for the tarball. It could be useful for "non-redistributable" software packages in the AUR. If you want to push the integration a little more, you can add 'file::/bin/true' in the DLAGENTS array of makepkg.conf.

trya commented on 2011-09-24 20:54

I'm not sure everyone will agree with you. In an ideal world, that's actually how all PKGBUILDs should look like, without any kind of interactivity. But this isn't a usual PKGBUILD: we're not trying to package a free (as in beer or as in speech) software, but a commercial game whose tarball is not freely available. Try "makepkg --source" with the PKGBUILD you suggested, you'll see what I'm talking about. However, I have an idea to get around this situation (which could involve switching from a local tarball to a distant location in the PKGBUILD source array). Please wait.

Anonymous comment on 2011-09-24 17:41

There is really no need for all that complexity in handling the source tarball.
If for some reason you don't want to have the actual data in $SRCDEST, just put a symlink there and it'll work, but don't hack the pkgbuild.

trya commented on 2011-07-11 20:35

@Ideka: the problem lies in the included libvorbisfile library. For an unknown reason (maybe glibc related), libvorbisfile is not able to load Ogg Vorbis files anymore... The glibc has been updated on June 26th, you posted on June 27th, that's why I think it's related. Still, I didn't got any error output from libvorbisfile, so I'm clueless. Better use system libraries for now, even if we're not safe from a soname bump some day, but it's manageable.


erick2red commented on 2011-07-11 15:19

@Ideka: Thxs for the tip, worked for me too !!!!!!!

Ideka commented on 2011-06-27 04:20

Thanks for the PKGBUILD!
When I first installed the game, the sound didn't work at all. After playing around a while with the configuration unsuccessfully, I tried commenting this line in /usr/bin/worldofgoo:
I don't know what it does, it was just a hunch, but it worked!
By the way, my system is x86_64.

trya commented on 2011-06-08 13:07

Corrected, thanks.

J4913 commented on 2011-06-08 12:32

The config.txt it talks about appears to be in /opt/WorldOfGoo/properties/ now (not /usr/share/worldofgoo/properties/).

trya commented on 2011-06-08 00:51

Adopted. Among the changes, game data is moved to /opt and icons are now integrated into the hicolor theme, as in the RPM and Debian packages.

Gently commented on 2011-05-24 17:28

Abandoning due to lack of time. Someone that knows the build please pick up. Thanks :).

Anonymous comment on 2011-05-14 17:25

I had to do the same as falconindy.

Add the line

to the PKGBUILD if you get into the strip error

falconindy commented on 2010-12-24 00:52

Build fails with error on 32-bit:

/usr/bin/strip:./usr/share/worldofgoo/libs64/ File format not recognized

The !strip option should be added.

Anonymous comment on 2010-05-31 04:38

If you click onto the green "Linux" button, you get the .tar.gz archive.
If you click onto the small "deb" or "rpm" links, you get the deb or rpm archive.
You can see this also in your browser's status bar.

CPUnltd commented on 2010-05-31 04:05

the humble indie bundle version comes in deb and rpm format only, is there a way to edit this package to be able to extract the game from the rpm or deb and install it? otherwise, I may be screwed. I requested the .tar.gz of the game, but haven't gotten any response as of yet... would hate to not be able to play this game now that I have it...

frb commented on 2010-05-26 21:39

I'm not sure but I think that the bundled libs provided in this pkg could be removed
Give a look at: pacman -Ql worldofgoo | grep -i lib

Anonymous comment on 2010-05-05 05:34

I think I should copy Slash's comment to worldofgoo-demo here:
world of goo is available for one week as "name your price" @

Svenstaro commented on 2010-04-29 14:37

Well, the thing is, binary blobs/application blobs should almost always go to /opt. Besides, /usr/share/games isn't even used by any Arch games packages known to me. I'm actually guilty of packaging one of my game packages to /usr/share/games myself but now I realize it should be in /opt.

Anonymous comment on 2010-04-29 03:02

In the case Gentoo has more games in /usr/share/<game-name> but for World Of Goo use /opt in Gentoo. I don't have idea about it.

Gently commented on 2010-04-29 02:48

Could you elaborate more Svenstaro? I seen /usr/share/<game-name> files before here. Gentoo (for example) uses /usr/share/games which I think is a good. Granted there is a binary here, but is linked to /usr/bin. Granted I could use /opt by it's definition is so ambiguous (if you can't think of anywhere else use /opt :)) to me. And if I remember correctly the .deb I found also uses /usr/share.

Svenstaro commented on 2010-04-28 21:33

The game really shouldn't go to /usr/share/worldofgoo. This will make the Unix file system structure sad. Please put it to /opt/worldofgoo instead.

Gently commented on 2010-04-02 07:40

Done. Hurrah.

muunleit commented on 2010-03-24 09:32

There is a minor mistake in the PKGBUILD.
It's "worldofgoo-gootool", not "worldofgoo-gootools", in optdepends=(). ;-)