Re: glest package - an analysis
On 11/08/06, Stefan Potyra <email@example.com> wrote:
thanks for stepping in here, I'm just -EOUTOFTIME right now :(.
Am Donnerstag 10 August 2006 15:29 schrieb Eddy Petrişor:
> #I'll take this, in the name of the Debian Games Team
> owner 350391 !
> I have looked over the glest package in REVU and tried to compile the
> package. I don't know what happens with this package, but it FTBFS for
Seems like you didn't look at the latest uploaded version to revu... it's
*This* is weird! I specifically remember REVU pointing to a package
older than the one that should have been, judjing from the REVU page.
I have deleted from the dsc url the trailing part and looked by hand
the most recent upload of glest, then using that link to get the
package via dget. Maybe I have mixed middle click paste and
(if you follow that link, and a newer version has been uploaded to revu,
you'll need to click on the latest date to switch to this upload. I know,
it's a little bit annoying that revu doesn't highlight what exact version
s.o. is looking at.)
> - not gcc 4.1 ready (lots of extraqualification erros)
This is fixed in the latter upload.
> - !!! the build process does *not* stop at any of these errors !!!
Oh, crap, just saw it:
"-cd mk/linux && jam"
Please note that it won't stop compiling the targets if one fails due to jam's
nature. IIRC "jam -q" could do that trick, but not sure though.
the package has just compiled, I'll look into the ignoring thingies
> - the glest binary is, of course, not created because many object
> files are broken, thus the dh_install rule fails when looking for that
> - I think there are some places where the result of a rule in a target
> is ignored, which might be problematic
> I'll try to package this game after I test it some more ;-)
The version I built for ubuntu works quite well, but I didn't test it on
unstable yet. Also I didn't come around testing multiplayer. (And the AI
always beats me *g*).
As a side note: the glest script will link the binary and the game data to
~/.glest, which I think is not the very best approach to do so. However that
way it's possible to dump custom maps to ~/.glest, which otherwise doesn't
seem possible. I didn't look at any code bits yet, maybe glest could be
customized to honour both DATADIR and ~/.glest.
Hmm, yes, that would be nice, but we will see.
"Imagination is more important than knowledge" A.Einstein