This classic game has been/is being ported to linux, and released under the GPL. Source and docs available from: http://sc2.sourceforge.net/
Created attachment 13315 [details] uqm-0.2.ebuild An ebuild of this game to fasten the process a bit. I don't know about the arch support, x86 seems to work. At the end portage seems to strip a lot. Just let it do that. Umm.. suggested category is app-games. Someone should probably come up with a better description.
Created attachment 14256 [details] uqm-0.2.ebuild
Added to CVS. Thanks for the ebuild Regan and Spanky - it was a real help in getting this bad-boy going. Note that the 0.2 release of UQM is still very buggy. If we start getting a lot of complaints about it, I'm going to mark them WONTFIX and direct people to this comment. If you want a real working version of this I think you have to use the CVS code or wait for the 0.3 release. At least the 0.2 release allows *some* fun though so in it goes.
Created attachment 14332 [details, diff] uqm.diff Well.. I don't like some things in the ebuild that went in.. Mostly my personal style preferences: - move some things from src_unpack to src_compile - no encapsulation breaks from catting, use <<-EOF, not <<EOF - mkdir's failure doesn't matter if cd works - using \ with && \ isn't necessary, && expects more things already - ugly but works: thing && another - but because we don't like ugly we use: thing \ && another - using ; for groupping is fine small fixes: - add IUSE - it doesn't ignore user's CFLAGS by default, the -O3 is just an addition to ${CFLAGS} in the script Also my name isn't Regan. Also when i do a for lib in $(ldd /usr/games/lib/uqm/uqm | awk '{print $3}');do qpkg -f ${lib}; done | sort -u it tells it depends on alsa-lib. Maybe someone with oss could tell if this doesn't work without alsa?
And, 0.3 alpha just released, more polished, a lot more stable. Probably not much more until 0.3 You guys going to add that one to the ebuilds? Definitely looking forward to it.
I just asked on #sc2 - that's 0.3 that was released, not 0.3 "alpha" the alpha refers to the game itself. So, with CVS at 0.31 now, would those people who made the original ebuild mind updating?
Sorry, but unless there is a compelling reason, we don't add CVS builds to portage. When the 0.31 tarballs are released then I'd be happy to take a look. Go ahead and file a new Games bug at that point. Thanks.
My point was more that the 0.3 tarball had been released, would anyone mind updating the ebuild to *that*. But I can file a new bug if you insist, just seems so wasteful. A new bug for each new release?
emerge uqm should get you what you want. Regarding the version stuff. Yes, a new bug is preferred. It's not wasteful since we have an unlimited supply of bug numbers. Having version bump requests helps us to keep track of things better. Obviously, if a game is under heavy development that there is a new release every day or something it's not desired but then I'd question the need to have the game in portage at all if that much development is still needed.
Well, from hanging out with the SC2 people, the game is pretty much legacy, but they are focusing on a lot of tweaks. Plenty of people who care about this game continually poking bits of it. Game itself is pretty stable. As for unlimited version numbers, I assure you from the Mozilla project this is far from the truth. The more bugs there are, the more bugzilla starts to strain in the searches. And single bugs help find stuff easily. Frankly, I think it'd be neat if there was a direct one-to-one association between each portage package and a particular bug.
Oh, re: that association thing, not to put all bugs for a package in a particular bug, but tracking bugs *can* be handy - versioning, ebuild tweaks, associations n such.
