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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
