Add Sauerbraten, the "next-gen" version of Cube to portage Reproducible: Always Steps to Reproduce:
Created attachment 72192 [details] sauerbraten-20050815.ebuild
Created attachment 72193 [details, diff] files/20050815-gentoo-paths.patch
Created attachment 78674 [details] sauerbraten-0.0.2006.01.31.ebuild Here is an ebuild for the 31-Jan-2006 version.
Compiles, installs and runs just fine. Please add to portage...
Created attachment 81067 [details] sauerbraten-0.0.2006.02.27.ebuild Version bump, with 28-Feb patch. Tidied my overenthusiastic RDEPEND.
works for me sauerbraten-0.0.2006.02.27.ebuild, please add to portage
Created attachment 81105 [details] sauerbraten-0.0.20060227.ebuild Tidied date versioning - date is no longer split in ebuild filename.
Looks to still be in heavy development so I'm not in a big hurry to add this to portage. Having the ebuild here for people to put in their local overlays is probably fine for now.
Multiple vulnerabilities, see http://aluigi.altervista.org/adv/sauerburn-adv.txt
oh goodie. well...in that case, reopen when they're fixed. Thanks.
*** Bug 126123 has been marked as a duplicate of this bug. ***
Created attachment 83051 [details] sauerbraten-0.0.20060320.ebuild Here is an ebuild for the 20060320 version (and the patch to physics.cpp). I haven't checked about the security issues.
*** Bug 127584 has been marked as a duplicate of this bug. ***
Created attachment 85513 [details] sauerbraten-20060426.ebuild New version released.
Changelog: http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=849 Sauerbraten 2006-04-26 release! by Aardappel_ # tweaks & fixes to the capture gameplay mode # added high resolution skyboxes, and some of the g_pack textures to the standard set # fixed newent sending invalid attributes in coopedit mode # models with a specularity of 0 now have a specialized shader ("nospecpvmodel") for faster drawing (mainly for vegetation) # grenadelauncher damage increased to max 75 # multiplayer players & flag models will not be culled no matter how far away they are # added waterfall effect for water material sides # added pistol ammo (ent type "cartridges") # added linearly-interpolated normals for lighting (controlled by "lerpangle", "lerpsubdiv", and "lerpsubdivsize" vars) # added HW occlusion culling support (requires NV GeForce3-class hardware or better) # height map mode. will hopefully allow for easier terrain editing. # reduced overdraw dramatically # reduced size of vertex data by using short instead of float # removed ZYX order inconistency from math classes # fixed lights placed outside the world not casting shadows # fixed grenades being stopped by clip material and being stuck in walls # made networking protocol use less bandwidth # calclight now uses multi-sampling and adaptive sampling # faster mapmodel ray intersects with spheretrees instead of bsp # shorter fuse on grenades (2 seconds) # fixed hudgun light computation related crash http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=798 Sauerbraten 2006-03-20 release! by Aardappel_ # registersound now allows individual sound volume adjustment # can now render md2s without back face culling (good for vegetation models), custom specularity, custom shader. # console now supports line-editing # calclight now forces a map remip automatically, and has 4 quality settings you can pass (see ref) # added workaround for texgen bug in nvidia drivers # added goal-oriented team player mode (mode 12, "capture", see game.html, try playing it on face-capture map) # added initial version of the grenade launcher # added macros to the scripting language # everything in the engine is now rendered using shaders # converted the engine's use of OpenGL from xzy to xyz (don't ask) # added phong lighting for models # added shader system, each world surface can now have its own shader, and maps can have their own shaders. Look at the shader and setshader commands. # reorganized directory structure # can now specify custom animations and other properties for md2s (see docs/dev/md2.txt) # clip material no longer stops bullets (only the glass material does) # added spectator mode (toggled by "spectator" command, or mastermode 2) # many mastermode bug fixes # fixed line wrapping to depend on screen resolution # added map model shadows for md2s (available in maximum quality mode of "calclight", see ref) # added Cube-like "replace" command that will repeat a texture edit across matching parts of a selection # maxhealth now persists across disconnects
Created attachment 89323 [details] sauerbraten-20060611.ebuild New release.
Just a tip: Works for me on amd64 with 'setarch i386 sauerbraten'. You will need at least 'setarch', 'emul-linux-x86-sdl', maybe more.
Created attachment 89519 [details] sauerbraten-20060611.ebuild Tidied ebuild.
Created attachment 92628 [details] sauerbraten-20060722.ebuild
Created attachment 92669 [details] sauerbraten-20060722.ebuild More ebuild tidying. The "map rotation" patch is not applicable.
>>> Source compiled. >>> Test phase [not enabled]: games-fps/sauerbraten-20050815 >>> Install sauerbraten-20050815 into /var/tmp/portage/sauerbraten-20050815/image/ category games-fps !!! ERROR: games-fps/sauerbraten-20050815 failed. Call stack: ebuild.sh, line 1539: Called dyn_install ebuild.sh, line 1013: Called src_install sauerbraten-20050815.ebuild, line 71: Called die !!! dohtml failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/overlay'
(In reply to comment #21) > 20050815 Use the ebuild at the *bottom* of the list ;)
$ sauerbraten init: sdl init: enet init: video: mode init: video: misc init: console init: gl Renderer: Mesa DRI R200 20040929 AGP 1x x86 TCL (Tungsten Graphics, Inc.) Driver: 1.3 Mesa 6.2.1 Using GL_ARB_vertex_buffer_object extension. WARNING: No shader support! Using fixed function fallback. (no fancy visuals for you) WARNING: No occlusion query support! (large maps may be SLOW) WARNING: Non-power-of-two textures not supported! init: world init: sound init: cfg init: localconnect init: mainloop read map packages/base/metl4.ogz (0.2 seconds) Mining Station by metlslime 2game mode is ffa/default Fatal signal: Segmentation Fault (SDL Parachute Deployed) Vertex3f: 1 Normal3f: 1 how to reproduce: the version: # emerge -av sauerbraten These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] games-fps/sauerbraten-20060722 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/overlay ->hit the esc key -->go to multiplayer ---->go to server browseer wait less than 10s and it will crash
Created attachment 96861 [details] sauerbraten-20060912.ebuild New version. Ebuild changes because of silly "edition" name in filename.
*** Bug 147644 has been marked as a duplicate of this bug. ***
Sauerbraten has today entered Portage. Is just "echo eat" in src_compile intentional?
i searched for open bugs, guess that's why i didnt find this one
SpanKY: your ebuild installs the binary only. wouldn't it be better to make this a sauerbraten-bin package and add the ebuild in this bug as sauerbraten? else other arches than x86/amd64 aren't able to use this.
i know it installs the binary only, i did that on purpose the cube package had a history of users annoying upstream because their build failed and/or because they were trying to use the source client with binary servers and that doesnt work
There might be version build from source, which show somewhere (in splash screen or as message in game) that could not be used to play in public network game servers.
Created attachment 100392 [details] games-fps/sauerbraten and net-libs/enet ebuilds, building from source I installed sauerbraten-2006.09.12 from portage on my amd64, and after resolving some missing dependancies (app-emulation/emul-linux-x86-*) I got it to work, but on maps with lots of monsters it was unplayable slow. So I decided to try to build from source to see if the performance increased. It did! Along the way I made some patching do get a more gentooish install, using system enet, supporting USE="dedicated", honouring CXX and CXXFLAGS, and installs stuff according to Gentoo policies and the FHS. The USE="dedicated" support needs some extra explaining: With USE="dedicated" it will only compile the standalone server (make server) and install it as /usr/games/bin/sauerbraten-server. No game data is installed (saves you about 100MB). Most importantly, however, is that it will compile without X and OpenGL (still needs libsdl). With USE="-dedicated" it will only compile the combined server/client (make client) and install it as /usr/games/libexec/sauerbraten. It will then install wrappers as /usr/games/bin/sauerbraten-{client,server} that manages the environment propperly (so it'll find the game data). The sole difference between the server and client wrapper is that the server wrapper passes the argument "-d" (for dedicated), making it a drop-in replacement for the standalone server. I've installed with USE="dedicated" on an x86 server without any trace of X or opengl, and USE="-dedicated" on my amd64 desktop. I've then tested to run the server both at both boxes, connecting to them with the client on my desktop. I've also run the client in singleplayer mode. All the above worked flawlessly. Connecting to internet servers fails however, and there is no chance of fixing that unless I get sauerbraten to output some debug messages...
It would be nice if someone could update the sauerbraten & enet ebuilds from source to 12/04/06 ;]
Created attachment 104570 [details] games-fps/sauerbraten-20061204 ebuild, building from source Here is an updated sauerbraten from-source ebuild. Unlike my previous ebuild, this one does not depend on system enet, as sauerbraten now requires, and ships with, a post 1.0 CVS snapshot of enet. Just as before I've installed with USE="dedicated" on an x86 server, and USE="-dedicated" on my amd64 desktop. I've then tested to run the server at both boxes, connecting to them using the client on my desktop. I've also run the client in singleplayer mode. All of this works just fine. This time even connecting to Internet servers seems to work (not extensively tested). However, every time I exit the client it will hang. To quit for real I have to run "killall -9 sauerbraten". May be a problem with my X, as I have the same problem in other games as well.
*** Bug 158245 has been marked as a duplicate of this bug. ***
Created attachment 104704 [details] games-fps/sauerbraten-20061204 ebuild, building from source I took a look at the ebuild in bug #158245 comment #3, and merged some of it's better parts with my ebuild. Also added the official server_crash_patch.tar.gz (which isn't a patch, but a replacement fpsserver.h), and fixed some documentation installation issues. Can also confirm that the previously reported crash at exit is specific to my system, as it works just fine on a friend's (x86) computer.
Yep, I can also say that it doesn't crash on exit for me.. Works great! Hope this makes it in the tree..
Attach files as text/plain please so they can be easily viewed.
Created attachment 104899 [details] sauerbraten-20061204-r1.ebuild Mr. Bones: There are five files, but sure, I'll upload them individually.
Created attachment 104900 [details, diff] files/sauerbraten-no-static-wiki.diff
Created attachment 104902 [details, diff] files/sauerbraten-20061204-makefile.diff
Created attachment 104903 [details, diff] files/sauerbraten-20061204-standalone.diff
Created attachment 104905 [details] files/sauerbraten.png
Where'd the png file come from and what license is it under? Have these patches been sent upstream yet?
The png is just the logo from tar:/usr/portage/distfiles/sauerbraten_2006_12_04_gui_edition_linux.tar.gz/sauerbraten/data/sauer_logo_512_256.png (could probably be generated at buildtime using imagemagic or similar). The license is a unspecified freeware license. However, I assume the png can be considered part of the ebuild, and thus be covered by: "You may re-compress using different archival formats suitable for your OS (i.e. zip/tgz/rpm/deb/dmg) [...]" (http://www.sauerbraten.org/README.html) The patches has not been submitted uppstream (yet). sauerbraten-no-static-wiki.diff is a workaround for broken portage (see comment in ebuild). Should not go upstream. The other patches should probably go upstream, as soon as I figure where I should send them (there is no mailing list and the sf.net tracker seems unused).
Created attachment 116408 [details] sauerbraten-20070415.ebuild Updated ebuild for the new sauerbraten release. The makefile patch only needs to be version bumped, the other patches follows below. I've run the same tests as with last version, with the same result. Everything seams to work. The makefile patch as well as the updated standalone patch has been sent to the private email address of the main developer, couldn't find any better email to upstream.
Created attachment 116410 [details, diff] files/sauerbraten-20070415-no-static-wiki.diff
Created attachment 116411 [details, diff] files/sauerbraten-20070415-standalone.diff
Sauerbraten version 2007.08.29 is in portage, version 2007.09.04 is out. The source ebuild works perfectly, except two points: * apparently the makefile patch was partially applied by upstream. * the standalone patch needs to be fixed I believe it is wrong to only have a binary version in portage, as gentoo is a source-driven distro. Specially since lots of users like me are on x86_64. Still there is no apparent effort to put the source ebuild in portage..
Created attachment 133448 [details] sauerbraten-20070904.ebuild Here is an updated sauerbraten 20070904 from-source ebuild. I must say that I don't really like the sauerbraten team's idea of how to do minor releases (making a tar.gz with changed files and calling it a patch), but anyway. Updated makefile and no-static-wiki patches to follow. The standalone patch isn't necessary any longer. Upstream only partially integrated my patch, but they did even better and the sauerbraten server don't even need libsdl now. That means that with USE=dedicated the ebuild don't have any dependencies. Just as before I've installed with USE="dedicated" on an x86 server, and USE="-dedicated" on my amd64 desktop. I've then tested to run the server at both boxes, connecting to them using the client on my desktop. I've also run the client in singleplayer mode. All of this works just fine. I've also made some rudimentary tests of internet play, and it seems to work just fine. Also no problems with quitting the game, but that is most likely due to me having a new Nvidia graphics card...
Created attachment 133449 [details, diff] files/sauerbraten-20070904-makefile.diff
Created attachment 133450 [details, diff] files/sauerbraten-20070904-no-static-wiki.diff
Sauerbraten "Assassin Edition" is out.
Created attachment 139476 [details] sauerbraten-20071222.ebuild Updated ebuild. Use the same sauerbraten.png as always. The no-static-wiki patch isn't necessary any longer as portage 2.1.2.4 and later don't break on filenames with spaces. If you are using an older version of portage when you install this ebuild you will get orphaned files if you uninstall it, and any future updates/reinstalls of sauerbraten will fail if you use FEATURES="collision-detect". Updated makefile patch to follow. As usual I've tested the game on an amd64 desktop, running in single mode, connected to a localhost server, to a x86 USE=dedicated server, and to a few random internet servers. All seems to work just great. It does NOT like my new Radeon HD 2600 card when using the radeonhd driver, but using latest fglrx it "just works". Considering the state of the radeonhd driver, I'm considering that a bug of the driver, not the game.
Created attachment 139478 [details, diff] files/sauerbraten-20071222-makefile.diff Updated makefile patch. This patch will make the Makefile honour the CXXFLAGS set in /etc/make.conf. Upstream doesn't seem to be interested in this behaviour, and forces "-O3 -fomit-frame-pointer" instead. I'm including this patch as I think /etc/make.conf is the proper way to go, but if you prefer to be closer to upstream you can easily drop it.
I only tried the latest version, and found some strange behaviours: When the dedicated useflag is set the ebuild ONLY installs the server. According to the description of the flag and the behaviour of most of the other ebuilds the server should be installed additionally to the client. If you want to make it possible to install only the server you should put it in an extra ebuild.
(In reply to comment #55) Well, saurebraten-client can't be installed without sauerbraten-server (or rather, the client act as the server if passed the "-d" flag, so it would be stupid not to provide the wrapper). Thus installing only the client is impractical, and providing and maintaining a separate ebuild providing only the server and blocking the client+server ebuild is even more impractical. The semantics of USE="dedicated" for this ebuild was explained in Comment #31, where it first appeared. And looking at a few other games ebuilds shows that most (such as wesnoth scorched3d freeciv openttd warsow) seems to remove the client with USE="dedicated", while a few (such as quake3-bin and ufo-ai) adds the server with USE="dedicated". When the use-flag dedicated removes the client, and the server is optional (eg wesnoth), it is instead enabled with USE="server". While this inconsistency is suboptimal, and should probably be addressed by the games heard, it's not a problem with my ebuild, at least not until the games heard has created a clear policy on what each use-flag should mean, and the usage in my ebuild contradicts that policy. If you want to advocate such a use-flag clean-up, please file another bug for that.
Created attachment 152457 [details] ebuild from sources as realeased and in binary ebuild on 20071227 This ebuild compiles Sauerbraten from the same sources used in official binary ebuild (latest is 20071227). It also adds icon (not perfect) to freedesktop menu entry and it changes game wrappers to save and reuse configuration under ~/.sauerbraten. No symlinks from ~/.sauerbraten to /usr/share/games/sauerbraten/* (as used in binary ebuild) are needed any more. New Makefile.diff is required.
Created attachment 152459 [details, diff] Makefile patch for 20071227 ebuild Adjusted patch for Makefile for 20071227 sources.
The "CTF edition" is out.
Created attachment 157443 [details] games-fps/sauerbraten-20080617.ebuild This is ebuild for source code release on 2008-06-17 (ctf edition). Makfile patch for 20071227 is required.
"CTF Edition" works fine here (amd64)... definitely something that should be commited to portage.
Created attachment 190408 [details] Cube 2: Sauerbraten Trooper Edition ebuild New release (Trooper Edition) is out, and I've updated my ebuild. Note that I've updated the ebuild to EAPI="2" so you might have to upgrade to a portage-2.2 release candidate for it to work. There isn't any need to patch the Makefile any longer, as it now respects CXXFLAGS set on the command line. Upstream has removed the in-development RPG Eisenstern from the sources. I have no clue what happened to it, but it's not included any more. In this release upstream have messed up the built-in dedicated server (passing "-d" to the client). It will refuse to run without an X connection (even though it is never used) and it don't quit when issued a Ctrl+C (kill -9 necessary). The stand-alone dedicated server still works though, so I decided to install it instead of the wrapper. Because of this change my arguments from Comment #56 above isn't valid any longer, so I changed the USE flags used. They now works as follows: 1) USE="client" installs the client. Default to enabled. 2) USE="server" installs the dedicated server. Defaults to enabled. 3) USE="master" installs the master server, new for this release. Defaults to disabled. I also made installing the documentation conditional on USE="doc" (disabled by default).
What needs to be fixed: 1) sync with main tree binary ebuild - there is better cvs removal command - also better handled configuration setting by wrapper command 2) remove enet from the build - you need to use in-tree enet ebuild instead of the bundled sources 3) detect client with dedicated useflag if not dedicated build also client 4) with g+w on STATEDIR you actualy create security hole so be really sure to do step 1 where you will get it working without sec. issues
Why don't you use -k, -q, -r options as I used in my ebuild instead of the nasty DOS stylish CWD games? This works with precompiled binary: /tmp/sauerbraten/bin_unix/linux_client -k/tmp/sauerbraten/ -q$HOME/.sauerbraten -r
Created attachment 190448 [details] Alternative ebuild for 20090504 This ebuild is based on Jon's ebuild (attachment #190408 [details]) however it transplants ideas from my previous ebuild (attachment #157443 [details]). It cleans CVS files in the same manner as in-portage binary ebuild. It doesn't create group writable directories. It uses dedicated USE flag. It uses games wrappers to start any of the three binaries with proper arguments. It does not use external enet library. I did not test its current version. At least the client part should work. What do you think? Is it better approach?
Created attachment 190465 [details] Cube 2: Sauerbraten Trooper Edition ebuild (In reply to comment #65) Your ebuild is better than mine, but it still has a couple of problems. I had missed the -k and -q switches, much better than my solution. However, even with -k and -q, sauerbraten will still reads files from ${PWD}, so it should probably be set anyway. Also, you broke the ability to run sauerbraten-server and sauerbraten-master as an ordinary user, as ${STATEDIR} no longer has g+w. To work properly without that they also have to use ${HOME}/.${PN}, which means that the server wrapper must copy server-init.cfg from somewhere to ${HOME}/.${PN} if it doesn't already exist. Additionally you broke the ability to change the directory of sauerbraten-master. The wrapper should only set the directory if none is specified on the command line. Also note that sauer_master requires it's directory to end with a slash... Not pretty, but that is the state of things. Attaching an ebuild based on Petr's ebuild but addressing these issues. Only issue left seams to be enet. I tried to build sauerbraten against net-libs/enet-1.2 in the tree, but that didn't work. It seams sauerbraten still requires a development snapshot of enet...
Created attachment 190468 [details] enet/enet-1.2_p20090328.ebuild A cvs snapshot ebuild for enet nessesary to build sauerbraten against system enet. It downloads the sources using cvs, but it's not a live ebuild as it always fetches the same revisions.sau If future sauerbraten releases requires newer enet, all you have to do is version bump this ebuild, as the revisions fetched are decided by the version number.
Created attachment 190470 [details, diff] games-fps/sauerbraten/files/sauerbraten-20090504-system-enet.diff Patch to the Makefile so that sauerbraten uses system enet.
Created attachment 190472 [details] Cube 2: Sauerbraten Trooper Edition ebuild New sauerbraten ebuild that uses system enet
(In reply to comment #66) > Created an attachment (id=190465) [edit] > Cube 2: Sauerbraten Trooper Edition ebuild > > (In reply to comment #65) > > However, > even with -k and -q, sauerbraten will still reads files from ${PWD}, so it > should probably be set anyway. > Are you sure? I explored previous release source code very deeply (writing I18N patch), I traced current binaries under strace, and I did not find any evidences of reading files from PWD if -k, -q options are used. I know the maintainer recommends to do cwd, but IMHO this is only to make things more compatible with win32 port. > Also, you broke the ability to run sauerbraten-server and sauerbraten-master as > an ordinary user, as ${STATEDIR} no longer has g+w. To work properly without > that they also have to use ${HOME}/.${PN}, which means that the server wrapper > must copy server-init.cfg from somewhere to ${HOME}/.${PN} if it doesn't > already exist. > I'm not sure why ordinary user should run server/master. There should be init script to do it. But I'm not proper player, thus do it as you want. > Additionally you broke the ability to change the directory of > sauerbraten-master. The wrapper should only set the directory if none is > specified on the command line. Also note that sauer_master requires it's > directory to end with a slash... Not pretty, but that is the state of things. > That's possible I did not tested it yet. > Attaching an ebuild based on Petr's ebuild but addressing these issues. > > Only issue left seams to be enet. I tried to build sauerbraten against > net-libs/enet-1.2 in the tree, but that didn't work. It seams sauerbraten still > requires a development snapshot of enet... > Yeah, the maintainer warns he doesn't use official enet release.
(In reply to comment #70) > Are you sure? I explored previous release source code very deeply (writing > I18N patch), I traced current binaries under strace, and I did not find any > evidences of reading files from PWD if -k, -q options are used. > > I know the maintainer recommends to do cwd, but IMHO this is only to make > things more compatible with win32 port. Well, I never checked the source code, but tested it the empirical way. When I gave an existing path other than ${DATADIR} as -k sauer_client would complain about being unable to load textures, unless ${PWD} was ${DATADIR} in witch case it worked. Additionally, the help page [1] for -k states that it *adds* the directory to the search path, and is intended for mods. In fact, looking at the documentation, it looks like using -k to locate ${DATADIR} might in fact break any mods that tries to replace files in ${DATADIR}, as they expect ${DATADIR} to be searched last rather than first. So perhaps we should only use ${PWD} and -q, not -k. [1] http://sauerbraten.org/docs/config.html#_minus_ks > I'm not sure why ordinary user should run server/master. There should be init > script to do it. But I'm not proper player, thus do it as you want. Well, I remember when I was younger and set up LAN with my friends. We always manually ran the dedicated server for whatever game we were playing (if there was one) on whatever computer was least busy at the time. So while init scripts would be great for more permanent installations, the ability to run the servers manually is also necessary. >> Only issue left seams to be enet. I tried to build sauerbraten against >> net-libs/enet-1.2 in the tree, but that didn't work. It seams sauerbraten >> still requires a development snapshot of enet... > > Yeah, the maintainer warns he doesn't use official enet release. But at least he uses unmodified upstream sources, so an upstream snapshot works. But whether doing that is worth the hassle is another question. Enet must be statically linked anyway, so if any security issues are found in enet, the sauerbraten ebuild still has to be bumped to force a rebuild...
(In reply to comment #71) > (In reply to comment #70) > > Are you sure? I explored previous release source code very deeply (writing > > I18N patch), I traced current binaries under strace, and I did not find any > > evidences of reading files from PWD if -k, -q options are used. > > > > I know the maintainer recommends to do cwd, but IMHO this is only to make > > things more compatible with win32 port. > > Well, I never checked the source code, but tested it the empirical way. When I > gave an existing path other than ${DATADIR} as -k sauer_client would complain > about being unable to load textures, unless ${PWD} was ${DATADIR} in witch case > it worked. > > Additionally, the help page [1] for -k states that it *adds* the directory to > the search path, and is intended for mods. > > In fact, looking at the documentation, it looks like using -k to locate > ${DATADIR} might in fact break any mods that tries to replace files in > ${DATADIR}, as they expect ${DATADIR} to be searched last rather than first. So > perhaps we should only use ${PWD} and -q, not -k. > > [1] http://sauerbraten.org/docs/config.html#_minus_ks > Actually current code searches both data and packages in order of -k options and as a last resort it tries PWD. E.g. "sauer_client -k/A -k/B" will search at first in /A, then in /B, and then in ".". Because we want to allow the user to overlay system files with his own mods, we must ensure the user supplied options will be placed before system provided -k option. Thus games_make_wrapper() is not suitable for adding -k option by ebuild. There must be CWD utilized. So you are right, the bes way is to avoid -k option from wrappers. Also some hints can be found in bin_unix/readme.txt.
Hint hint: - write init script for the sauerbraten master/server (take look onto boinc how i did it). way better than the script - make one common wrapper (as i patched the one in the binary one) and make it detect the filename and do the correct calls. - for configs: client ${home}/.${pn}; server /etc/${pn}-server ; master /etc/${pn}-master (sidenote /etc/ is actualy variable ${GAMES_SYSCONFDIR}). - also there is doicon command, guess where it should be used - you can drop both virtual deps they get pulled in anyway So far good work, and i am sorry i can just rant about it and not help much, there is too many work blobing from kde and mesa (uuf 180 mails for last 2 days). About enet we shall see how it will be handled when we get to it, so far the snapshot ebuild is good idea. :] Cheers
Created attachment 190546 [details] Cube 2: Sauerbraten Trooper Edition ebuild OK, new ebuild, with new wrappers and an init script. Auxiliary files will follow. (In reply to comment #72) > So you are right, the best way is to avoid -k option from wrappers. Done. (In reply to comment #73) > Hint hint: > - write init script for the sauerbraten master/server (take look onto boinc > how i did it). way better than the script Done. Tough I still install wrappers as well, so you can still run the servers from the command line if you want to. > - make one common wrapper (as i patched the one in the binary one) and make it > detect the filename and do the correct calls. After lots of thought I decided not to do this. Instead I'm using games_make_wrapper for the client and dedicated server, and a custom wrapper for the master server. When I tried to do a combined wrapper for all three, all I ended up with was a big bloody mess. Doing a shared wrapper for the client and dedicated server would be trivial, but that is essentially what games_make_wrapper is anyway. > - for configs: client ${home}/.${pn}; server /etc/${pn}-server ; master > /etc/${pn}-master (sidenote /etc/ is actualy variable ${GAMES_SYSCONFDIR}). After lots of consideration I decided to do it slightly different: * The client always uses ${HOME}/.${PN} * The dedicated server run by the init-script uses ${GAMES_SYSCONFDIR}/${PN} by default (configurable in /etc/conf.d/sauerbraten) * The dedicated server run bsudy the wrapper uses ${GAMES_SYSCONFDIR}/${PN} as base, but lets you override it in ${HOME}/.${PN} * The master server run by the init-script uses ${GAMES_SYSCONFDIR}/${PN} by default (configurable in /etc/conf.d/sauerbraten) * The master server run by the wrapper uses ${HOME}/.${PN} as it must have write permissions in the directory > - also there is doicon command, guess where it should be used Done. > - you can drop both virtual deps they get pulled in anyway Done. > So far good work, and i am sorry i can just rant about it and not help much, > there is too many work blobing from kde and mesa (uuf 180 mails for last 2 > days). No problems, I just hope that my work end up in the portage tree this time. ;) > About enet we shall see how it will be handled when we get to it, so far the > snapshot ebuild is good idea. :] OK.
Created attachment 190547 [details] sauerbraten init script
Created attachment 190548 [details] configuration file for sauerbraten init script
Created attachment 190550 [details] sauerbraten-master wrapper
*** Bug 268900 has been marked as a duplicate of this bug. ***
(In reply to comment #77) > Created an attachment (id=190550) [edit] > sauerbraten-master wrapper > use [[ sometest ]] it is new syntax, actualy the old should be awoided where possible :]
(In reply to comment #75) > Created an attachment (id=190547) [edit] > sauerbraten init script > Your init and conf is not avare any subdirectory in etc as i said that it should use the /etc/games/something and now it is just plainly using /etc/games/ so master would overwrite the server configs.
Also runmakster and runserver checks are to much vague, they check only for Yes user might add there YES or yes :] so just tr it to lowercase and check for it :]
Created attachment 190622 [details] sauerbraten init script (In reply to comment #79) > (In reply to comment #77) >> Created an attachment (id=190550) [edit] >> sauerbraten-master wrapper > > use [[ sometest ]] it is new syntax, actualy the old should be awoided where > possible :] Actually, [[ sometest ]] is the bash extended version, while [ sometest ] is the POSIX standard version. Thus you should never use the [[ version unless you use #!/bin/bash rather than #!/bin/sh or it will break if /bin/sh isn't bash. While I could change that too, I see no need to force bash as I'm not using the extended features... In fact, I should replace [[ with [ in the init script as well, so that it works on OpenRC systems where /bin/sh isn't bash (baselayout-1 uses /bin/bash, but OpenRC uses /bin/sh). (Note that the PMS requires the use of /bin/bash for all current EAPIs, so using bashisms in ebuilds are OK.) (In reply to comment #80) > (In reply to comment #75) > > Created an attachment (id=190547) [edit] > > sauerbraten init script > > Your init and conf is not avare any subdirectory in etc > as i said that it should use the /etc/games/something and now it is just > plainly using /etc/games/ so master would overwrite the server configs. Please note SYSCONFDIR="${GAMES_SYSCONFDIR}/${PN}" at the top of the ebuild, analogues to the pre-existing DATADIR="${GAMES_DATADIR}/${PN}" just above it. As I sed ${SYSCONFDIR} into the init-script and conf-file, the init-script will use /etc/games/sauerbraten on a default system (where ${GAMES_SYSCONFDIR} is /etc/games). (In reply to comment #81) > Also runmakster and runserver checks are to much vague, they check only for > Yes, user might add there YES or yes :] so just tr it to lowercase and check > for it :] Fixed, along with removing the bashisms in the init script.
Oh i thought that openrc implicitly wants the bash too, sorry for that, and you are right in that case :]
*** Bug 246487 has been marked as a duplicate of this bug. ***
Created attachment 190657 [details] sauerbraten-2009.05.04.ebuild Few minor qa tweaks, mark obsoletes
Created attachment 190660 [details] sauerbraten-2009.05.04.ebuild fix typo. Actualy when i use git i have to make sure i commit all stuff and dont forget to do git add before commit. Later i grab nonfinal version for bugs posting :( I should create postcommit hook slapping me if i do so (happens to me quite often)
(In reply to comment #86) Looking through your ebuild I have two questions: 1. I'm not overly fond of the 2009.05.04 naming scheme. It's not as if 2009 is the major version, 04 the minor version, and 04 the micro version. A new major release can happen the same year, and a patchlevel release can happen the next year. Any reason why using 20090504 as version numer is a problem? 2. Why is it not a fatal error if the ebuild fails to install the binaries etc, while it is a fatal error to fail to install the documentation?
(In reply to comment #87) > 2. Why is it not a fatal error if the ebuild fails to install the binaries etc, > while it is a fatal error to fail to install the documentation? Sorry, forget this, just me who misread the diff file I made badly.
(In reply to comment #87) > (In reply to comment #86) > Looking through your ebuild I have two questions: > > 1. I'm not overly fond of the 2009.05.04 naming scheme. It's not as if 2009 is > the major version, 04 the minor version, and 04 the micro version. A new major > release can happen the same year, and a patchlevel release can happen the next > year. Any reason why using 20090504 as version numer is a problem? > > 2. Why is it not a fatal error if the ebuild fails to install the binaries etc, > while it is a fatal error to fail to install the documentation? > 2nd you answered yourself ;] 1st well i like it dot separated because it is even better readable, and if they release new version this year you just rename it to 2009.08.08. It does not matter actualy how it is named but i try to keep the same convence that we already have in the tree. Usualy the date without . is used for live snapshots. For the patches release, usualy the ebuild should get only -r1 and the patch should be added into it, the package version should not be bumped. Now we have to wait for games team to give their comments to the thing you created and i just bit adjusted :] Cheers
Ok i placed all stuff to my dev overlay, with some syntax improvements. So feel free to clone it: http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=summary direct links: http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=blob;f=net-libs/enet/enet-1.2_p20090328.ebuild http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=blob;f=games-fps/sauerbraten/sauerbraten-2009.05.04.ebuild
The SRC_URI in https://bugs.gentoo.org/attachment.cgi?id=190660 is wrong. It should be: SRC_URI="mirror://sourceforge/${PN}/${PN}_${PV//./_}_${EDITION}_linux.tar.bz2" This is fixed in your ebuild from git, i think it should also be fixed in the one attached here.
whats keeping this ebuild from going into main tree?
we really need to an up to date ebuild for current version of sauerbraten in the current portage
http://sourceforge.net/projects/sauerbraten/files/ shows a patch_2009_06_19_linux.tar.bz2
Created attachment 199353 [details] sauerbraten-2009.05.04-r1.ebuild (In reply to comment #94) > http://sourceforge.net/projects/sauerbraten/files/ > shows a patch_2009_06_19_linux.tar.bz2 Sorry for not noticing. Sourceforge is supposed to automatically send me an email when a file is uploaded, but either they didn't or my spam filter caught it. Anyway, here is a updated ebuild fixing the SRC_URI issue pointed out by comment #91 as well as adding the new patch. Otherwise identical to attachment #190660 [details] by Tomáš Chvátal. Games Team: The version in portage is starting to get outdated. Any chance of including this one any time soon?
Latest ebuild & patch posted by Jon works for me on ~amd64
Client from sauerbraten-2009.05.04-r1.ebuild works on ~x86. Server code not tested.
Is there any chances to see new ebuilds in tree? Client seems to be working fine since may and as a multiplayer game it's important to have newer version
Just wanted to inform you that my sauerbraten ebuild works just fine with enet 1.2.1 from portage, so my snapshot ebuild isn't necessary any longer. Also, if it would help the inclusion of this in the portage tree, I'm willing to act as proxy maintainer [1] for sauerbraten. [1] http://hwoarang.silverarrow.org/?p=555
Any news? 2009.05.04 even got removed from the scarabeus-overlay :-(
Created attachment 239489 [details] sauerbraten-2010.07.19.ebuild New release of Sauerbraten "Justice Edition"
Created attachment 239491 [details, diff] Patch to use system enet Patch for new release to use system enet. This as well as ebuild based on previous versions provided here. Thanks.
enet is slotted in portage now so the ebuild should reflect that.
Created attachment 239493 [details] sauerbraten-2010.07.19.ebuild You're right, it looks like enet 1.3 is the version included in the game normally, so i changed dependency to enet:1.3
Hi! Thanks a lot for your work on maintaining this ebuild. If you like you could join our gamerlay overlay and maintain it there. For review and contact please join our #gentoo-gamerlay irc on freenode.
Created attachment 239593 [details] sauerbraten-2010.07.19-r1.ebuild @Paul Hartman: Your ebuild will link dynamically to libenet but doesn't include enet in RDEPEND. You need to either add enet to RDEPEND or add "[static-libs]" to the dependency and change the patch to force static linking. Imho dynamic linking is preferable, so I updated the ebuild accordingly. Also updated the copyright year and changed the URL to match the new directory structure on SourceForge's mirrors. They do redirect from the old url, but the round-trip is unnecessary...
(In reply to comment #106) > Created an attachment (id=239593) [details] > sauerbraten-2010.07.19-r1.ebuild > > @Paul Hartman: Your ebuild will link dynamically to libenet but doesn't include > enet in RDEPEND. You need to either add enet to RDEPEND or add "[static-libs]" > to the dependency and change the patch to force static linking. Imho dynamic > linking is preferable, so I updated the ebuild accordingly. > > Also updated the copyright year and changed the URL to match the new directory > structure on SourceForge's mirrors. They do redirect from the old url, but the > round-trip is unnecessary... Thanks, I tried yours and it works for me.
Sauerbraten 2010_07_21 is out, but it is still into the 2010_07_19 dir and it fails to extract: ".. sauerbraten_2010_07_21_justice_edition_linux.tar.bz2 is not a bzip2 file." Can we also add RESTRICT="mirror" so gentoo mirrors are excluded?
Created attachment 239789 [details] sauerbraten-2010.07.19-r2.ebuild (In reply to comment #108) > Sauerbraten 2010_07_21 is out, but it is still into the 2010_07_19 dir and it > fails to extract: ".. sauerbraten_2010_07_21_justice_edition_linux.tar.bz2 is > not a bzip2 file." They seems to have messed up the linux tarball, and pulled it. They have re-uploaded a working version now, but make sure to remove the broken version from your distfiles before trying again. The correct sha256sum is 8a55c44a1e9736fab179fcd577d6f026a6b2a97c84f09f00d2c51ce3bfd7e4cf I also tried to make the ebuild more future proof regarding future releases. For a new edition, bump the filename, set the correct EDITION, reset FILE_VERSION and comment PATCH_VERSION. For minor updates (such as this one) set the correct FILE_VERSION and/or PATCH_VERSION. (In reply to comment #108) > Can we also add RESTRICT="mirror" so gentoo mirrors are excluded? RESTRICT="mirror" means that the gentoo mirrors are not *allowed* to mirror the file due to license restrictions. Using it in overlays to save a few 404-file-not-found is bad practice as it would cause a problem if/when the ebuild is added to portage...
Created attachment 240635 [details] sauerbraten-2010.07.19-r3.ebuild Version 2010-07-28 is out, updated the ebuild with the new file version, based on Jon's -r2 ebuild.
(In reply to comment #110) > Version 2010-07-28 is out, updated the ebuild with the new file version, based > on Jon's -r2 ebuild. An updated ebuild is also available in the gamerlay overlay (available through layman). I intend to keep updating the ebuild in that overlay until it gets added to portage proper.
sauerbraten-2010.07.28.ebuild is in portage.
