Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
On Tue, Jul 30, 2013 at 8:17 PM, chrysn wrote:
> given that the game only displays its own static strings and usually
> ships the font file, i'd assume upstream will stay with sdl ttf, but i
> asked anyway.
The main advantage of fontconfig is not having to hard-code font
pathnames at build time nor in git. If you add pango/QuesoGLC then you
get fallback on secondary fonts, which is mainly useful for l10n.
> my impression was that it's a mixture of copy/pasted and one-shot import
> from somewhere else, possibly an ad-hoc process -- but i've asked for
> clarification here too.
Ok, thanks.
> that's the default value upstream ships in the make file. as it is
> packaged, i patched the make file to only -O3 if the flags are not given
> from outside, so it shouldn't affect debian. (the original makefile
> didn't respect any environment variables.)
Hmm, I missed that, ok.
> the build process is a single gcc invocation. --parallel wouldn't do
> anything, would it?
Right now no,
> given how rare upstream changelogs are outside of top-of-class
> upstreams, i sometimes wonder why this is even a check.
It is a pedantic level check, as a reminder to talk with upstream
about their development practices.
> done. should the .ico file remain in /usr/share/pixmaps? (i assume no.)
No, leave that out of the binary package.
> i wasn't aware of that tool, good to know, thanks and done.
Lots of useful stuff in devscripts.
> i blame the poor resolution to #277441.
>
> just kidding, now i know of the tool, fixed and done.
I would have liked lintian to run more tools but that doesn't seem to
be the direction taken so far.
> on my box, i got segfault crashes for single argument tests.
>
> i'm not sure exactly why, but they are related to hyper segfaulting when
> no DISPLAY variable is set (failure to check for SDL_Init return code).
> now runs flawlessly; probably the x server was under too heavy load, sdl
> didn't get proper windows back, and behaved as if the x server was gone.
Hmm, ok.
> i'm under the impression that this kind of thing might happen again --
> i've already spotted another zero pointer dereference
> (03-worm-segfault.patch), which might be indicative of a general
> sloppyness with respect to zero pointers and exit codes, but my stance
> on this is that it's sufficient quality for a game which neither has
> elevated privileges nor reads untrusted data.
Sounds reasonable.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: