Mainly just a heads-up at this point: With 0.2.8 we, the Armagetron Advanced team, will be moving to a new version scheme. Odd minor releases will be more often and considered experimental. The ebuilds for these will be SLOTted into "experimental" and keyworded with "~arch" on platforms. Even minor releases will undergo more testing (both the experimental releases and the normal beta/RC stages) and will be considered stable by the .0 release. Ebuilds will be SLOTted into "0" and keyworded with "arch" on platforms they have been tested on. Beta/RC even minor releases will be in SLOT "0", but with "~arch" (maybe?) Our alpha releases will be simple CVS snapshots, which puts them as a separate armagetronad-cvs package, following Gentoo's usual methods. The SLOT/KEYWORD stuff above is what will be in our 'official' ebuilds, and what we recommend for Gentoo's use, too. We'd like ebuild-related bugs to go upstream, if possible, since that's mainly where it will be maintained-- perhaps some notice in metadata.xml?
Created attachment 82180 [details] 0.2.8.0 RC ebuild 20060314 Current ebuild for latest b0_2_8_0 CVS branch. Comments and suggestions welcome, especially with regards to handling the games paths (the Linux design is somewhat expecting binreloc).
Created attachment 82259 [details] 0.2.8.0 RC ebuild 20060315 This seems to work properly. Just a bit of cleanup and an accompanying tbz2 and it should be good to go. Comments are of course still welcome, especially those regarding acceptance to the Portage tree.
Also, if someone has modular X setup, the ebuild could use porting for it... I'm not messing with it for now. http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml has a HOWTO.
Created attachment 82260 [details] 0.2.8.0 RC ebuild 20060315-2 Looks like someone already ported 0.2.7.1 to modular X, so I did the same with this ebuild.
Created attachment 82261 [details] metadata with upstream maintainership
Created attachment 82452 [details] Armagetron Advanced 0.2.8.0 ebuild overlay This ebuild overlay should contain all the files needed to fetch (eg, distfiles not included), build, and install Armagetron Advanced 0.2.8.0 final. Note: profiles/use.local.desc must be merged with your existing one!
Created attachment 82603 [details] updated ebuild with some suggested changes Thanks to Mr_Bones and people in #gentoo-dev-help who made suggestions.
Created attachment 82604 [details, diff] patch required for 0.2.8.0
Created attachment 82605 [details, diff] add local use flags to use.local.desc
Same stuff applies to 0.2.8.1!
Looking at the ebuild: 1. http://usuario.tiscalinet.es/hgctiscali/naflat/downloads/spanishvoices.zip is just an html file that is displaying a banner and downloading the true file. Not good for gentoo :(. Should point to a zip file directly, or mirror at gentoo. 2. || ( virtual/x11 x11-libs/libX11 ) actually should be reverted, otherwise it is trying to get the virtual (at least that was what I 've been heard) 3. It seems that to me that the server and the client are compiled indipendently. That is good if they have no shared file. But is a waste of time/CPU if they share a lot last but not least. It seems to me that the ebuild is a mess. As I understand you are in the upstream team. If you can make a cleaner build system from upstream, all the distro can get it easily.
1) That's strange, it must have just changed; it worked when I wrote the ebuild and at least for a while, since all tests of it have been successful. I copied the file into our distribution system, so http://beta.armagetronad.net/fetch.php/PreResource/spanishvoices.zip will now redirect to our preferred mirror. 2) According to http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml , the preferred order is indeed reversed from what I have, since it makes modular X the default. Easy fix. 3) They are, yes. Since the difference is a #define, there is no current way to guarantee any object file to be common. Modifications to the build system to handle building both dedicated and client in the same run are planned for the 0.3 development line. However, that does not apply to 0.2.8. 4) I got a late start on the ebuild, and didn't have something until rc4. Unfortunately, it revealed many bugs in our directory handling, thus the mess with regard to that and it took a while to convince the team that FHS compliance to the book was not a good requirement to add. When 0.2.8.2 is released, it should make a significant reduction to the complexity of the ebuild, but for the current releases, I'm not sure there is much better to be done.
I'm not talking about the bug. I'm worried about the distance of your ebuild to the standard: egamesconf emake make install DESTDIR=${D} sequence. If, as I understand, you are upstream, you better change the build system to a more compatible one. If you are not, well, nothing could be done, apart from talking to upstream
The distance is accounted for by: - Turning Gentoo's boolean 'debug' flag into a numeric debug level; this could be made to work with '--with-debug[=level]' in future releases - Building the dedicated server and client separately; building them together is certainly possible and desired, but will take some work before it is functional; hopefully by the next stable release - Hard coding paths and disabling binreloc; fixed for 0.2.8.2 (in theory, anyway; need to do some testing) - Symlinking ~games/.armagetronad to the relevant directory; 0.2.8.2 should allow the environment to override HOME, which will make this no longer necessary - Installing add-ons such as the moviepack and moviesounds based on USE flags; can be made into a '--with-moviepack[=filepath]' option for the next stable release, which is planned to download the new moviepack data on first demand (cache-style). - Adjusting dedicated server configuration for Gentoo's preferred paths; might be fixed in 0.2.8.2 - Moving documentation to Gentoo's special documentation structure As 0.2.8.1 is already released, none of these can be removed from its ebuild. Some will go away once 0.2.8.2 is released, but that is yet another version bump which is for the future to be added to Portage. Until then, the ebuild will be a bit longer than usual.
thanks, fixed
not really ... ebuild needs to be cleaned up first - drop the use debug warning from pkg_setup - move all that config crap out of pkg_setup and into src_compile where it belongs - what is with all the crappy hacks in aabuild() ? screwing with configure and config.h ?
Created attachment 85908 [details] armagetronad-0.2.8.1.ebuild better?
- DESCRIPTION has retarded quotes - *DEPEND has stupid indenting (one tab only) - configure is still funky (wtf ln ?) - config.h hacks still present - bunch of variables without declared 'local'
- Who gave you the right to reject a description given by the creators? - To remove the linking of configure, you'll need to fix egamesconf so it can run outside of the source directory - config.h hacks are required for this version
> - Who gave you the right to reject a description given by the creators? the same person who added me as a Gentoo dev Gentoo dev's have domain over ebuilds, creators have domain over their packages > - To remove the linking of configure, you'll need to fix egamesconf so it can > run outside of the source directory already been done, why dont you re-read games.eclass > - config.h hacks are required for this version so you're saying you've made the code in current cvs/svn/whatever not suck ?
> > - Who gave you the right to reject a description given by the creators? > > Gentoo dev's have domain over ebuilds, creators have domain over their > packages The ebuild *is* the 'package'. Besides, domain over ebuilds does not mean domain over descriptions. > > - To remove the linking of configure, you'll need to fix egamesconf so it > > can run outside of the source directory > > already been done, why dont you re-read games.eclass Sorry, I don't read CVS logs... At the time, it was a problem. I'll put out a new ebuild using ECONF_SOURCE in a bit... > > - config.h hacks are required for this version > > so you're saying you've made the code in current cvs/svn/whatever not suck ? As much as practical in the time I've had. But in regard to this specific issue, config.h hacks should no longer be needed for CVS code (and 0.2.8.2 when released).
> Besides, domain over ebuilds does not mean domain over descriptions. sure it does if you have a problem with that, close the bug as WONTFIX
If I were to opt for WONTFIX, would I be able to get an ebuild into Portage stating something to the effect of Gentoo no longer supports the game and to use layman to add our overlay? Just curious, mostly. I'm not going to nitpick descriptions *that* much.
WONTFIX means we won't fix it, so it definitely wouldn't go into the tree.
*** Bug 133350 has been marked as a duplicate of this bug. ***
Let me know if you get 2.8.2 working, and post a ebuild... I hacked my own 2.8.1 ebuild before discovering this bug, but with my hacked ebuild and 2.8.2, I get this... Error: Error in tString GeneratePrefix() in tools/tDirectories.cpp:1332 : Relocation error. The binary was supposed to be installed into /usr/games/bin and found itself in /usr/games/lib/armagetronad and could not find out what this means for the prefix /usr/games. I'll download your 2.8.1 and see if it has the same issue with 2.8.2...
Created attachment 89476 [details] armagetronad-0.2.8.2.ebuild Version bump; the sysintall.in's patch is not needed anymore. Works like a charm on amd64. Please commit in CVS! :D
Created attachment 89481 [details] armagetronad-0.2.8.2.ebuild this new version still doesnt address the crappy build system
Created attachment 94185 [details] armagetronad-0.2.8.2.ebuild new, much cleaned up ebuild
Would be very happy to see this in the tree, just hoping :)
Looks like we'll need to force in 0.2.8.2.1 thanks to the security bugs in 0.2.8.2, or am I wrong about that?
Created attachment 95521 [details] armagetronad-0.2.8.2.1.ebuild yeah version 0.2.8.2.1 is needed http://genstef.homelinux.org/local/games-action/armagetronad/armagetronad-0.2.8.2.1.ebuild
Seeing that the digits after 0.2.8 are merely bugfix revisions, all 0.2.8.x should have the same keywords. It makes no sense to have the only difference between "arch" and "~arch" be that "arch" has more bugs than the latter. "~arch" should be used for 0.3.0, followed by 0.3.1 etc, and in a separate SLOT.
Of course, since my ebuild that would have easily been usable for both 0.2.8 and 0.3 was rejected, you're on your own with 0.3 and such. Unless I or someone else feels like updating the official 0.2.8.1 ebuild for recent releases, which we might end up doing anyway and setup our own overlay...
I do not get why you want this slotted. The same ebuild works perfectly without slots for 0.3.0: http://genstef.homelinux.org/local/games-action/armagetronad/armagetronad-0.3.0.ebuild
Because 0.2.8 is stable and 0.3 is not even meant to be?
well, some people might prefer to use 0.3.0. But I do not see the point in having _both_ - they do the same anyway. And it is not like gcc where we are having problems with building packages or qt where we need multiple versions to build against. IMO SLOTting makes no sense here.
Maybe they prefer 0.2.8 for stability, but one of their favourite servers requires 0.3?
- you do not need to link configure anymore, use ECONF_SOURCE - remove the filter-flags - why do you need to override $armabindir ? the build system should use the value of @bindir@ given to it by configure - do not install things into /usr/sbin - i dont understand the $DedHOME cruft
Created attachment 95621 [details] armagetronad-0.2.8.2.1.ebuild http://genstef.homelinux.org/local/games-action/armagetronad/armagetronad-0.2.8.2.1.ebuild All done and commented about the dedhome thing: # have var data in /var/games instead of /usr/games/.$PN
i'd replace the echo/eval with egetent ...
*** Bug 146446 has been marked as a duplicate of this bug. ***
(In reply to comment #40) > Created an attachment (id=95621) [edit] > armagetronad-0.2.8.2.1.ebuild This creates the symlink "armagetronad-dedicated-init" in /usr/games/bin, which points to /usr/share/games/armagetronad/scripts/rcd_server, but this file does not exist - at least not without USE=dedicated. So I suggest making dosym ${GAMES_DATADIR}/${PN}/scripts/rcd_server \ ${GAMES_BINDIR}/${PN}-dedicated-init conditional. [ebuild R ] games-action/armagetronad-0.2.8.2.1 USE="-debug -dedicated -krawall opengl videos" LINGUAS="-es" 0 kB [1] Also I'd like to see the video USE flag renamed to something more appropriate (perhaps simply "moviepack"), because it installs pictures (used as in-game decoration) and sounds, not videos.
http://wiki.armagetronad.net/index.php/Gentoo_Portage_Overlay
Please, add in ebuild in src_install section the following (for example) for creating a menu entry for this game: make_desktop_entry armagetronad "Armagetron Advanced" /usr/share/pixmaps/${PN}.ico It works with current stable release in portage tree, I couldn't test it with this newer version :-( Thanks
pacho: 0.2.7.1-r2 already includes this line, and the others should make the menu entry as well (albeit another way). If you are having problems with an ebuild from the overlay, please let me know either by email or posting on http://forums.armagetronad.net/viewforum.php?f=4 Thanks
Could someone please prepend this to profiles/package.mask? Thanks # Luke-Jr <luke_armagetronad@dashjr.org> (12 Jan 2007) # The Armagetron packages in Gentoo's repository are obsolete. # Please add the Armagetron overlay to upgrade: # emerge -a layman # layman -ka armagetron games-action/armagetronad
FTR, http://bugs.gentoo.org/show_bug.cgi?id=65931 is the origin of filter-flags-- can anyone vouch for sure that they can go, or should we try to contact Donald R. Gray Jr?
(In reply to comment #46) > pacho: 0.2.7.1-r2 already includes this line, and the others should make the > menu entry as well (albeit another way). If you are having problems with an > ebuild from the overlay, please let me know either by email or posting on > http://forums.armagetronad.net/viewforum.php?f=4 > > Thanks > Ok, I have added armagetron overlay and menu entry is properly created :-),thanks I have installed /armagetronad-0.2.8.2.1 and it works fine. Why these ebuilds aren't being added to official gentoo portage tree? Thanks for information
Frankly, because "SpanKY" just doesn't want to and nobody else wants to step on his toes.
(In reply to comment #50) > Frankly, because "SpanKY" just doesn't want to and nobody else wants to step on > his toes. > Ah :-| Ok, thanks for information
(In reply to comment #50) > Frankly, because "SpanKY" just doesn't want to and nobody else wants to step on > his toes. > You're giving wrong information. The majority of the game team devs reject this ebuild, and you can see from the comments. From the discussion we had, I remember that we all agree that is not good enough, and hence not easy mantainable. If someone step on this ebuild and clean alot, fixing all the problem described here, we are open to reconsider this.
No, it's not really wrong information. All real problems mentioned in the history of this bug have been solved where practical, and it would be plain unreasonable for you to demand we change our build system upstream immediately just to suit Gentoo-- I haven't seen any other package or game demanded they adhere to Gentoo's systems.
Maybe that is just because we didn't include you in that discussion? We've asked several people to change things to better suit us, most are receptive, some are not. When people aren't, we don't add it. Of course, it probably would be best for us to just remove what we have in the tree currently, since it isn't up-to-date anymore and "UPSTREAM" has their own set of ebuilds. We don't think they're good enough for inclusion, but we don't have to support them in an external overlay, either, so it's win/-win as far as I see it. Anyway, I've added the mask to the tree.
Created attachment 114632 [details] armagetronad-0.2.8.2.1.ebuild Cleaned ebuild (althought, not clean enough). Please, comment on those points and anything you see wrong. * USE flags: opengl -> client opengl flag was confusing. People actually want to choose between client and server, not between "server", "whatever with opengl" or "server and whatever with opengl". So opengl flag was renamed to client, and GL* to CLIENT*. * USE flags: music music support added but... where's the music? * Spanish voices Prior ebuilds disable spanish voices when both linguas_en and linguas_es are enabled. I don't get this choice. People with both es and en linguas set are likely to be Spanish native speakers so they may prefer Spanish voices. So I reversed this behavior and added a warning about that, but I suppose that upstream have something to say about it (Luke, are you looking around?)... Also... this warning should go on pkg_setup() or pkg_postinst() ? * CFLAGS filtering flags filtering was removed due to SpanKY's request. Is it actually needed? * SLOTs SLOT support dropped atm, it wasn't working at all. * Uninstall scripts I disabled uninstall scripts. Installing them is totally pointless when a package manager is handling it. The problem is that build system doesn't behave correctly on my tests when I use --disable-uninstall, So I have two workarounds, one is patching sources and another is use --enable-uninstall and remove uninstall scripts on src_install(). Of course, it'd be better to get --disable-uninstall working properly. * Init script Also removed and replaced by a "draft" of a Gentoo-compliant one. * Desktop entry: AA installs its .desktop and icons into /usr/share/games/armagetronad/desktop/armadetronad.desktop and then symlinks it on /usr/share/applnk/armagetronad.desktop (Icon is installed into /usr/share/icons too) Is this appropiate?
Created attachment 114633 [details, diff] armagetronad-0.2.8.2.1-uninstaller-stuff.patch Workaround for --disable-uninstall errors.
Created attachment 114635 [details] armagetronad-0.2-initd Init script.
Created attachment 114637 [details] armagetronad-0.2-confd daemon conf file.
0.2.8.2.1 doesn't support music. I don't think the configure switch does anything. English has a wider range of users who know it, so it should be preferred over Spanish. If someone is a native Spanish speaker and can't handle English, they should LINGUAS=-en The uninstall scripts merely wrap to portage when setup properly. This is to allow us to have a single uninstall command across all OSes that works correctly in each case.
(In reply to comment #59) > 0.2.8.2.1 doesn't support music. I don't think the configure switch does > anything. > > English has a wider range of users who know it, so it should be preferred over > Spanish. If someone is a native Spanish speaker and can't handle English, they > should LINGUAS=-en I'm sure that nobody who doesn't speak Spanish have LINGUAS=es. So we're talking about people who speak English and Spanish and with an high probability of being Spanish native speakers. > The uninstall scripts merely wrap to portage when setup properly. This is to > allow us to have a single uninstall command across all OSes that works > correctly in each case. But, who use it on Gentoo? Every Gentoo user knows how to type emerge -C armagetronad but, surely, they don't know that armagetronad-uninstall exists. If all programs installed such an uninstall scripts wrapping Portage I'd consider it cruft and immediately kill one Gentoo dev or two. Anyway, It's not that bad to install it... ;-) Also, armagetronad-dedicated-uninstall could cause confusion, because people could think that it uninstalls only armagetron-dedicated, when it actually uninstalls client and server.
(In reply to comment #59) > 0.2.8.2.1 doesn't support music. I don't think the configure switch does > anything. Ok, thanks.
(In reply to comment #55) > * USE flags: opengl -> client Change this back. We don't want client USE flags on any games. If you're wanting to make things a bit more "user-proof" then go for the default_client function, like we use on games-fps/darkplaces to determine which to build. > Also... this warning should go on pkg_setup() or pkg_postinst() ? It should go in pkg_postinst, like most other notifications. > * Desktop entry: > AA installs its .desktop and icons into > /usr/share/games/armagetronad/desktop/armadetronad.desktop > and then symlinks it on /usr/share/applnk/armagetronad.desktop > (Icon is installed into /usr/share/icons too) > Is this appropiate? Nope. Appropriate would be installing the .desktop entry to /usr/share/applications and the icon to /usr/share/pixmaps. You can use the "domenu" and "doicon" portage functions for this.
Created attachment 166709 [details, diff] armagetronad 0.2.8.2.1 patch used by armagetronad-0.2.8.2.1-r1.ebuild hi I've get armagetronad from armagetron overlay, but compilation going fail, because i'm using gcc4.3, and i've write a patch thate solve the compilation error and some warning.
Created attachment 166711 [details] armagetronad-0.2.8.2.1-r1.ebuild this is the ebuild that use armagetronad-gcc43.patch good look zeld
Created attachment 166773 [details, diff] Fixes bugs in Armagetron 0.2.8.2.1 necessary to compile with autoconf 2.60 and GCC 4.3
Finished armagetronad-0.2.8.2.1-build-fixups.patch, which includes GCC 4.3 fixups. It is now applied by the overlay ebuild, though the revision is not bumped as these are only build fixes.
0.2.8.3.1 in portage, if you have issues with it, open new bugs
Overlay/official ebuild updated with improvements in Samuli's rewrite. Should be good to copy into the main Gentoo tree (fixing the deficiencies in the rewritten one).
Please copy the official/working/proper/whatever ebuild from our overlay...
(In reply to comment #69) > Please copy the official/working/proper/whatever ebuild from our overlay... > I've just looked at the version in overlay, and it still doesn't look sane/readable/per gentoo standards to me
Better than the one currently in the tree... cmake is coming with 0.4, but that's still a bit off I think.
good times.
The in-tree ebuild is still screwed up.
it works fine for me so we'll stay with that, thanks.
Well then find someone in Gentoo who cares about quality assurance, or maybe at least copyright.
masked for removal.
