[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glest package - an analysis

On 11/08/06, Stefan Potyra <sistpoty@ubuntu.com> wrote:
Hi Eddy,

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 !
> thanks
> Hello,
> 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
> me.

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
shift+insert paste.

(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
> file
> - 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

Reply to: