Created attachment 446770 [details] powdertoy-9999.ebuild: Live ebuild for beta/snapshot builds of the Powder Toy I wrote a couple of ebuilds for the Powder Toy, a physics sandbox game where you can build a lot of different things from the various substances that are available in the game. I did search the bug tracker for any bugs pertaining to the Powder Toy, and found one for a mod of the vanilla game that was submitted in 2012. The ebuilds I've written are for the vanilla game, so I decided to file a new bug. Anyway, the 2 ebuilds are both live ebuilds. One of them is for beta builds (powdertoy-9999.ebuild) that pulls the sources directly from upstream's master development branch (https://github.com/simtr/The-Powder-Toy). The other one is for the stable version of the game (powdertoy-91.5.9999.ebuild), and that pulls from the stable branch (https://github.com/simtr/The-Powder-Toy/tree/stable). I did not see any tarballs of the source code for the stable version of the game, which is why the ebuild I'm uploading for it is a live ebuild. Chances are that if an ebuild for the stable version hits the tree, then it won't pull sources directly from the project's stable branch. In addition to that, there's a patch both of these ebuilds need to apply to the project's SConscript so that the cpu_flags_x86_sse2 flag will actually work properly. Without it, the SConscript will build with SSE2 optimizations enabled no matter what unless scons is called with the --no-sse option, which will disable all SSE optimizations. With that, there's also a .desktop file and an icon inside the FILESDIR that the stable ebuild uses. The stable branch doesn't have either of these files in the resources directory, but the master branch does, so I copied the .desktop file and the powder-48.png icon from the master branch to the FILESDIR. Then I modified that .desktop file to point to where the powder-48.png icon will be installed, so that the stable version of the Powder Toy will have a desktop menu entry and a corresponding icon, just as the beta version does. I will tar up the patch, .desktop file, and icon together and upload that here along with the 2 ebuilds. Please let me know if the ebuilds need any fixes or improvements.
Created attachment 446772 [details] powdertoy-91.5.9999.ebuild: Live ebuild for stable version of the Powder Toy
Created attachment 446774 [details] Gzip compressed tar archive containing patch, .desktop file, and icon
Thanks for your work! Would you be interested in becoming a proxied maintainer? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Some comments about the ebuild: * On the github page, there are some releases with tarballs: https://github.com/simtr/The-Powder-Toy/releases Why can't you use one of them? * You can omit the src_prepare function. Its default version will automatically be called. * The construction of the command line for escons looks very complicated. Can't you build it step by step: scons_args="--debugging --symbols" [add sse args...] if ! use lua; then scons_args+=" --nolua" fi if ! use fftw; then scons_args+=" --nofft" fi escons ${scons_args} * Is there maybe some way to let "escons install" do the installation? * No need to "|| die" after do* functions. They do it on their own. * eutils has domenu and doicon functions. You might want to use them.
(In reply to Felix Janda from comment #3) Thank you for taking the time to respond, Felix. > Would you be interested in becoming a proxied maintainer? > > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers I'm tempted to say yes, but I need to look through everything more thoroughly before I have a definitive answer. I will get back to you on that. In the meantime, I did make improvements to the ebuilds. I'll upload them soon. > * On the github page, there are some releases with tarballs: > > https://github.com/simtr/The-Powder-Toy/releases > > Why can't you use one of them? Cool! Looks like I didn't look around GitHub thoroughly enough to find them. I updated the stable ebuild so that it'll use them. The stable ebuild is no longer a live ebuild. > * You can omit the src_prepare function. Its default version will > automatically be called. I went ahead and removed that from both of the ebuilds. > * The construction of the command line for escons looks very complicated. > Can't you build it step by step: > > scons_args="--debugging --symbols" > [add sse args...] > if ! use lua; then > scons_args+=" --nolua" > fi > if ! use fftw; then > scons_args+=" --nofft" > fi > escons ${scons_args} That is a much nicer way to do it compared to what was there previously! I updated both ebuilds to use that kind of construct. > * Is there maybe some way to let "escons install" do the installation? No, unfortunately. I took a look at the project's SConscript and didn't see an install target defined in there. That's why the install process is done manually in the ebuilds. > * No need to "|| die" after do* functions. They do it on their own. Okay, I removed that from the do* functions used in the ebuilds. > * eutils has domenu and doicon functions. You might want to use them. Those are now used in the ebuilds. Thank you for your guidance. I really appreciate it! Are there any other changes that should be made?
Created attachment 447008 [details] powdertoy-9999.ebuild: Live ebuild for beta/snapshot builds of the Powder Toy This ebuild implements various fixes/improvements that were suggested by Felix Janda in comment 3.
Created attachment 447010 [details] powdertoy-91.5.330.ebuild: Ebuild for stable version of the Powder Toy Normal ebuild for the stable version of the Powder Toy. Various fixes/improvements that were suggested by Felix Janda in comment 3 were implemented.
Created attachment 447012 [details] Gzip compressed tar archive containing patch, .desktop file, and icon The powder.desktop file in the archive has been changed. The icon path points to where doicon installs the powder-48.png icon.
Thank you for the ebuild! I put the powdertoy-91.5.330.ebuild stable version and its files into my overlay and everything seems to be going well so far. :) A few notes (note: I'm not a Gentoo dev, so take these with a grain of salt): 1. As I understand it, it's preferred to use the dobin/dolink/etc install functions rather than using the cp/ln commands directly - https://devmanual.gentoo.org/function-reference/install-functions/index.html . The "Trivial installs" section at https://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html shows some of these commands in use. (In fact, not using these is causing a slight issue with the /usr/bin/powder symlink; it's linking to "//usr/bin/powder64" rather than "/usr/bin/powder64". It still works, but dobin/etc know how to deal with the ${D} variable correctly.) 2. Powder Toy pops up a dialogue on first use, asking if you want to install the Powder Toy. Looking at the upstream code in src/client/Client.cpp , it appears that this uses the tools from xdg-utils to install icons, file associations and MIME types. You already install an icon in the ebuild, which makes this a little redundant (and kinda confusing). You may want to patch the code so that it never does its "installation", and then install the file associations/MIME types yourself. (On a similar note, check out the xdg and xdg-utils eclasses; they might help!) 3. A minor thing; it looks like Powder Toy saves its preferences file as "powder.pref" in the current directory. That seems like a Bad Thing; I don't know what Gentoo's policies are on that but it would probably be preferable to patch it to explicitly use the $XDG_CONFIG_HOME (or "$HOME/.config" if not defined) directory instead. Thanks again for the ebuild - I love this toy and I'm happy to see an ebuild for it! :)
One more thing; although this ebuild doesn't yet conflict with the 'powder' binary installed by games-roguelike/powder, it'll only be a matter of time until it does - the /usr/games/bin directory that games-roguelike/powder installs into is deprecated as of about a year ago (see #574082 and https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt ), so at some point that package is going to get updated to use /usr/bin. In light of this, it may be a good idea to use "powdertoy" as the executable/symlink name instead of "powder". (But this may be something that's better pushed upstream, honestly.)
Hello, Sophie. Thanks for the feedback! You are right with regard to your first point. I also didn't consider a potential conflict between this and games-roguelike/powder, so the /usr/bin/powder binary (or symlink) as-is in both ebuilds are problematic. I notice that games-roguelike/powder-117-r1 already moved it's binary to /usr/bin, so I need to address this sooner rather than later. So, in light of that conflict, I decided to rename /usr/bin/powder to /usr/bin/powdertoy using the newbin install function. I also decided to forgo the symlinks for the sake of consistency. I originally had the ebuilds symlink, for example, /usr/bin/powder64 to /usr/bin/powder so that there would be the option of running the program using upstream's name for the binary if the user wanted to run it that way, in addition to consistency. I think it would be weird if I renamed it, but kept the symlinks to the original binaries for instances where the binary name wouldn't conflict with Powder. I also updated the desktop file in the FILESDIR to point to /usr/bin/powdertoy. With regard to your second point, I was also confused by that when I was working on the ebuild. I haven't installed the Powder Toy on my own machine prior to doing that (I've only used it on a friend's machine, and used a much older version on a Wii console). I will definitely look into using the xdg and xdg-utils eclasses so that the ebuild will install those file associations and MIME types instead of the program doing it itself (if you say yes to its installation dialog). I will also try patching the code so that it won't do it's installation, but it's going to be a while before I can do that. I need to acquaint myself with C++ before I mess with the code. Anyone is welcome to beat me to the punch, but until then... And finally, I thought the Powder Toy would actually store powder.pref in the root of the home folder, but I only thought that because I've only ran it when my current directory was the root of my home folder. I cd'd into a different directory, ran the Powder Toy, and there was a new powder.pref in the directory I was in. Definitely seems like a Bad Thing that needs to be fixed. Having it stored in $HOME/.config/powdertoy, or something like that, would be a much better option. Thanks again for the feedback! I will upload the new ebuilds along with the files soon.
Created attachment 459584 [details] powdertoy-91.5.330.ebuild: Ebuild for the stable version of the Powder Toy /usr/bin/powder was renamed to /usr/bin/powdertoy to address the conflict with games-roguelike/powder. Newbin install function is used instead of using cp directly. Symlinks are no longer used. Other issues mentioned by Sophie Hamilton in comment 8 have not been fixed yet, but will be in the future.
Created attachment 459586 [details] powdertoy-9999.ebuild: Live ebuild for the beta/snapshot builds of the Powder Toy /usr/bin/powder was renamed to /usr/bin/powdertoy to address the conflict with games-roguelike/powder. Newbin install function is used instead of using cp directly. Symlinks are no longer used. Other issues mentioned by Sophie Hamilton in comment 8 have not been fixed yet, but will be in the future.
Created attachment 459588 [details] Gzip compressed tar archive containing patch, .desktop file, and icon The desktop file has been updated to point to the /usr/bin/powdertoy binary instead of /usr/bin/powder.
Created attachment 469014 [details] powdertoy-9999.ebuild: Live ebuild for the beta/snapshot builds of the Powder Toy It's been a while since I've been able to do anything with the ebuilds for this program (life has gotten in the way). This is only a small fix for the live ebuild. The README file was renamed to README.md upstream, so I modified the ebuild to reflect that.
