new game. not found in portage. Reproducible: Always
Created attachment 111062 [details] actioncube-0.92.ebuild Working ebuild.
*** Bug 178703 has been marked as a duplicate of this bug. ***
Renamed to Assault Cube with new version 0.93
Created attachment 121603 [details] Not finished ebuild, don't use. i'm working with one hand because my right hand is hurt, this is only a draft for someone who want to take this and continue the work, thnx and sorry.
I'm a little concerned by the status of this. I read that the binary (closed source) in the tar is compatible with the official game server, while with the source you can build one that is not. I don't know what to install. Care to explain? Actually, with the game in this state, this ebuild will not have any loving care, at least from me.
Just came across this game/bug, would be quite nice to have an ebuild for it. The license is explained here: http://assault.cubers.net/wiki/Interpretation_of_AssaultCubes_license
Hi all. I'd really like to see assaultcube in the portage tree, so I've written an ebuild for it, based on the sauerbraten ebuild. It doesn't install any precompiled binaries because the docs say they don't use precompiled binaries for cheat protection like cube did. I've left the conditional dependencies for amd64 from the sauerbraten ebuild, but I've not done anything specific to amd64 with the remaining dependencies, because I don't have an amd64 machine to test with. I also don't know how the server stuff is supposed to work, so if anyone wants to try to fix the ebuild to install the ac_server_wizard and assaultcube_server scripts correctly, please do.
Created attachment 173900 [details] /usr/local/portage/games-fps/assaultcube/assaultcube-1.0.ebuild =assaultcube-1.0.ebuild
Created attachment 173902 [details] /usr/local/portage/games-fps/assaultcube/files/assaultcube =wrapper script:files/assaultcube
Created attachment 173904 [details] /usr/local/portage/games-fps/assaultcube/files/assaultcube_server wrapperscript:files/assaultcube_server
Created attachment 173905 [details] /usr/local/portage/games-fps/assaultcube/files/ac_server_wizard files/ac_server_wizard
Hi, If you want it in portage so badly i sugess you to use sunrise overlay. http://gentoo.org/proj/en/sunrise We are helping users with ebuild, reviewing it etc. So if you want to add to sunrise just drop by #gentoo-sunrise on irc.freenode.net.
That won't really help it get into portage faster unless you continue to attach updates here as well.
(In reply to comment #13) > That won't really help it get into portage faster unless you continue to attach > updates here as well. > Actualy we do the reviews. that means you get mostly ready ebuild. es there might be some minor flaws but basicaly it gets better than iusualy. And sunrise is nice storage for stuff bfore it hits tree. Tell me how many users browse bugzilla in order to get some package. In sunrise it is all in one big pile ;] Also if you see in-sunrise keyword it is easy to click trhought trac/websvn/gitweb and pick the ebuild.
I to am interested in an ebuild for this game. I took a quick peek at the ebuild supplied here. (sorry I do not have time to fix it). Anyway here are some ideas: * Use my CXXFLAGS instead of the provided * Ability (useflags) to build server,client or both * Use enet from portage Maybe when I have time this weekend I'll fix it.
I just noticed that when using the net-libs/enet in portage that compiling won't continue. And a bunch of errors will be shown: And this is only when doing "make server": /usr/include/enet/enet.h: In function ‘ENetSocket httpgetsend(ENetAddress&, const char*, const char*, const char*, const char*, ENetAddress*)’: /usr/include/enet/enet.h:406: error: too few arguments to function ‘ENetSocket enet_socket_create(ENetSocketType, const ENetAddress*)’ serverms.cpp:29: error: at this point in file serverms.cpp:30: error: ‘enet_socket_bind’ was not declared in this scope serverms.cpp: In function ‘void serverms(int, int, int, char*, int, const ENetAddress&)’: serverms.cpp:165: error: ‘ENetSocketSet’ does not name a type serverms.cpp:166: error: ‘sockset’ was not declared in this scope serverms.cpp:166: error: ‘ENET_SOCKETSET_EMPTY’ was not declared in this scope serverms.cpp:167: error: ‘ENET_SOCKETSET_ADD’ was not declared in this scope serverms.cpp:169: error: ‘enet_socketset_select’ was not declared in this scope serverms.cpp:181: error: ‘ENET_SOCKETSET_CHECK’ was not declared in this scope /usr/include/enet/enet.h: In function ‘void servermsinit(const char*, const char*, int, const char*, bool)’: /usr/include/enet/enet.h:406: error: too few arguments to function ‘ENetSocket enet_socket_create(ENetSocketType, const ENetAddress*)’ serverms.cpp:267: error: at this point in file serverms.cpp:268: error: ‘enet_socket_bind’ was not declared in this scope /usr/include/enet/enet.h:406: error: too few arguments to function ‘ENetSocket enet_socket_create(ENetSocketType, const ENetAddress*)’ serverms.cpp:276: error: at this point in file serverms.cpp:277: error: ‘ENET_SOCKOPT_REUSEADDR’ was not declared in this scope serverms.cpp:277: error: ‘enet_socket_bind’ was not declared in this scope This is bad package behavior!
Created attachment 174344 [details] assaultcube-1.0.ebuild This is a modified version of the ebuild. I am happy to tell that it works fine on amd64 (native). The enet bug is still there. I have requested upstream to make assaultcube compatible with enet-1.2 (the latest stable version).
Created attachment 174891 [details] New makefile New makefile so we can build the server without all the graphic stuff. ac_server_wizard is no longer necessary when building from source.
Created attachment 174893 [details] Updated ebuild Updated ebuild. Server now builds without graphics stuff. Repoman no longer wines. Execpt about the use flags.
Created attachment 178478 [details] assaultcube-1.0.ebuild It didn't worked for me with ~amd64 since it's installed in /usr/games/lib64/assaultcube but CUBE_DIR is set to /usr/games/lib/assaultcube Since game is installed in $(games_get_libdir)/${PN} I think that CUBE_DIR should be replaced with this value.
Created attachment 185053 [details] Makefile for ebuild 1.0.2 Version 1.0.2 makefile
Created attachment 185058 [details] assaultcube-1.0.2.ebuild (In reply to comment #20) > Created an attachment (id=178478) [edit] > assaultcube-1.0.ebuild > > It didn't worked for me with ~amd64 since it's installed in > /usr/games/lib64/assaultcube but CUBE_DIR is set to /usr/games/lib/assaultcube > Since game is installed in $(games_get_libdir)/${PN} I think that CUBE_DIR > should be replaced with this value. > You are of course right. I did not have a change to test it in AMD64. Anyway new bumped makefile (and for the sake of it new bumped ebuild..., yours.. with a different name). So we can now enjoy assault cube 1.0.2 :D
Choosing between server and client via use flags is really a bad idea, and a pain. Especially when trying to emerge world.
(In reply to comment #23) > Choosing between server and client via use flags is really a bad idea, and a > pain. Especially when trying to emerge world. > You do not have to choose you can just compile both.
G(In reply to comment #24) > (In reply to comment #23) > > Choosing between server and client via use flags is really a bad idea, and a > > pain. Especially when trying to emerge world. > > > > You do not have to choose you can just compile both. > No, I mean the fact that use flags pick which program(s) is/are installed is stupid. There should be either 2 ebuilds, or the single ebuild should always build the client unless "-client" is given. Emerging it without any use flags fails completely. It should cleanly emerge *something* even if no flags are set.
There is a newer version available, 1.0.4. The new version is in the form of an update you have to apply after installing 1.0.2, and I'm not quite sure how to apply that from an ebuild.
It wont run for me, it goes to a black screen for a second and returns, then outputs this: me@localhost /usr/games/lib64/assaultcube $ ./ac_client init: sdl init: net init: world init: video: sdl init: video: mode init: video: misc init: gl Renderer: GeForce 9800 GTX/9800 GTX+/PCI/SSE2 (NVIDIA Corporation) Driver: 3.2.0 NVIDIA 190.42 couldn't load texture packages/misc/notexture.jpg could not find core textures (hint: run AssaultCube from the parent of the bin directory) (Couldn't open packages/misc/notexture.jpg) Which is true when I'm not in the assaultcube directory, but if I change to it, I get this in strace: ... open("packages/misc/notexture.jpg", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0640, st_size=40680, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0341f33000 lseek(11, 0, SEEK_CUR) = 0 lseek(11, 0, SEEK_SET) = 0 read(11, "\377\330\377\340\0\20JFIF\0\1\2\1\0H\0H\0\0\377\341\20\344Exif\0\0MM"..., 4096) = 4096 lseek(11, 4096, SEEK_SET) = 4096 lseek(11, 4096, SEEK_SET) = 4096 ... It's opening and reading the file, so it's clearly giving a bad error message... This happens with the compiled binary as well.
(In reply to comment #27) > It wont run for me, it goes to a black screen for a second and returns, then > outputs this: > > me@localhost /usr/games/lib64/assaultcube $ ./ac_client Did you install the Makefile and assaultcube/assaultcube_server scripts (from attachments in this bug) into the files dir with your ebuild? You should run the game by "assaultcube" script, not running ac_client directly.
Created attachment 229597 [details] AssaultCube 1.0.4 ebuild Here is a VERY HACKISH ebuild for AssaultCube 1.0.4. I also changed "client" USE variable to "noclient"; in other words, it will built client by default unless you specifically ask it not to by setting the "noclient" USE variable. Use the same Makefile and scripts already attached to this bug from the previous version. An ebuild guru could probably do a much better job with it. FWIW :)
(In reply to comment #29) > Created an attachment (id=229597) [details] > AssaultCube 1.0.4 ebuild > > Here is a VERY HACKISH ebuild for AssaultCube 1.0.4. I also changed "client" > USE variable to "noclient"; in other words, it will built client by default > unless you specifically ask it not to by setting the "noclient" USE variable. > > Use the same Makefile and scripts already attached to this bug from the > previous version. Sure u uploaded the right file ? SRC_URI states 1.0.2 , better use ${PV} there. u might be interested in the global dedicate use flag, look at other games how they use it (drop X dependencies and just built a server)
Hi, i've rewritten the ebuild, and talked to nyhm, preferred use flags were dedicted to build a server and opengl to build client and depends on graphics. All bundled libs were stripped, {LD,CXX}FLAGS respected. Patches sent to upstream. It's committed to sunrise overlay and will be at http://overlays.gentoo.org/proj/sunrise/browser/reviewed/games-fps/assaultcube soon. (See http://overlays.gentoo.org/proj/sunrise/browser/sunrise/games-fps/assaultcube for preview.)
(In reply to comment #31) > Hi, i've rewritten the ebuild, and talked to nyhm, preferred use flags were > dedicted to build a server and opengl to build client and depends on graphics. > All bundled libs were stripped, {LD,CXX}FLAGS respected. Patches sent to > upstream. > > It's committed to sunrise overlay and will be at > http://overlays.gentoo.org/proj/sunrise/browser/reviewed/games-fps/assaultcube > soon. > (See > http://overlays.gentoo.org/proj/sunrise/browser/sunrise/games-fps/assaultcube > for preview.) > I just tried this new ebuild but it failed to compile for me. What version of enet does it depend on? I've got net-libs/enet-1.2.1 installed and compilation fails as below: g++ -march=native -O3 -floop-interchange -floop-strip-mine -floop-block -ggdb -pipe -I../src `sdl-config --cflags` -c -o serverbrowser.o serverbrowser.cpp /usr/include/enet/enet.h: In function 'void pingservers(bool, serverinfo*)': /usr/include/enet/enet.h:407: error: too many arguments to function 'ENetSocket enet_socket_create(ENetSocketType)' serverbrowser.cpp:348: error: at this point in file make: *** [serverbrowser.o] Error 1
(In reply to comment #32) > I just tried this new ebuild but it failed to compile for me. What version of > enet does it depend on? I've got net-libs/enet-1.2.1 installed and compilation > fails as below: > > g++ -march=native -O3 -floop-interchange -floop-strip-mine -floop-block -ggdb > -pipe -I../src `sdl-config --cflags` -c -o serverbrowser.o serverbrowser.cpp > /usr/include/enet/enet.h: In function 'void pingservers(bool, serverinfo*)': > /usr/include/enet/enet.h:407: error: too many arguments to function 'ENetSocket > enet_socket_create(ENetSocketType)' > serverbrowser.cpp:348: error: at this point in file > make: *** [serverbrowser.o] Error 1 I can confirm this for version enet-1.2.1. I've written the patch for enet-1.2 . Looks like enet switched their api back to the old one. It works w/o the -enet.patch. This works as a quick fix: http://dpaste.com/193857/ The "g++" doesn't look ok to, i review this ebuild and push a new version to sunrise.
(In reply to comment #33) > (In reply to comment #32) > > I just tried this new ebuild but it failed to compile for me. What version of > > enet does it depend on? I've got net-libs/enet-1.2.1 installed and compilation > > fails as below: > > > > g++ -march=native -O3 -floop-interchange -floop-strip-mine -floop-block -ggdb > > -pipe -I../src `sdl-config --cflags` -c -o serverbrowser.o serverbrowser.cpp > > /usr/include/enet/enet.h: In function 'void pingservers(bool, serverinfo*)': > > /usr/include/enet/enet.h:407: error: too many arguments to function 'ENetSocket > > enet_socket_create(ENetSocketType)' > > serverbrowser.cpp:348: error: at this point in file > > make: *** [serverbrowser.o] Error 1 > > I can confirm this for version enet-1.2.1. I've written the patch for enet-1.2 > . Looks like enet switched their api back to the old one. It works w/o the > -enet.patch. > > This works as a quick fix: http://dpaste.com/193857/ > > The "g++" doesn't look ok to, i review this ebuild and push a new version to > sunrise. > Thanks, new version compiles now, but the game didn't work for me... either freezes on loading screen, or loads with completely corrupt graphics. When I compiled again with the ebuild attached to this bug instead, the game works properly. So I don't know exactly what's different about them. (I'm using nvidia-drivers)
(In reply to comment #34) > Thanks, new version compiles now, but the game didn't work for me... either > freezes on loading screen, or loads with completely corrupt graphics. When I > compiled again with the ebuild attached to this bug instead, the game works > properly. So I don't know exactly what's different about them. (I'm using > nvidia-drivers) Yeah, i was able to reproduce it (nvidia driver). It's a problem introduced by the replacement of the bundled enet lib with system enet. enet-1.2 with the patch worked here, libenet 1.2.1 w/o the patch crashed. So reverted this and removed the replacement of the shipped libenet. Will be in sunrise soon.
There is a new version: 1.1.0.1
Created attachment 261288 [details] assaultcube-1.1.0.4.ebuild Updated ebuild for version 1.1.0.4. One problem is with the icon. winicontoppm and ppmtoxpm were used in a previous ebuild, but this returns an error: winicontoppm: Can't handle compressed icons This ebuild just copies the .ico file rather than convert, but my XFCE environment doesn't display the icon. Since I'm not using winicontoppm or ppmtoxpm in this ebuild, I removed netpbm from DEPEND.
1.0.4 which is NOW present in sunrise overlay fails to emerge, due to non-existing 1.0.2(ebuild pulls it) tarball anymore. Please push suggested 1.1.0.4 to sunrise. Otherwise, current ebuild is non-functional.
Bumped in sunrise, at least it's fetchable now ;)
Created attachment 387194 [details] assaultcube-1.2.0.2.ebuild with bundled enet This ebuild probably isn't meet to QA, but it works for me (instead of one based on assaultcube-1.1.0.4.ebuild from sunrise overlay). Soon I will rewrite that ebuild. Notes and recommendations are welcomed
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
Sunrise is unsupported and discontinued. Package is no longer in the Portage tree.
