On Thu, 2012-06-28 at 09:03 +0100, Simon McVittie wrote: > On 27/06/12 23:10, Svante Signell wrote: > > The attached patch adds support for the GNU/Hurd architecture > > Thank you for porting it. Do the resulting binaries work correctly? In > particular, can Linux clients join a Hurd dedicated server and > interoperate correctly?
Will test soon, bbl. > To test it, you'll need a very similar patch for openarena (the build > system is almost identical). I have now patched and built openarena. Care for a new bug report? > You could also use Quake III Arena if you > own a copy, Yes, I happen to have one. Don't know what to install from the CD though, the pak0.pk3?? file and ? > but openarena is a better test anyway, because our patched > version exercises the native-plugin-loading code path. > > My main concerns about things that might not work or interoperate are: > > * networking (BSD sockets implementation) Will test that out. > * graphics/sound, for the client (does Hurd have any accelerated 3D? > If not, it's likely to be unplayable - seconds per frame rather than > frames per second) Is it the server or client that provides the audio/video? From your question I guess it is the client. Unfortunately Hurd does not have 3D support yet, so it will probably be seconds per frame. > * native-code game logic loading (debian/q3arch, Makefile and > q_platform.h all need to end up with the same name for the OS and > architecture) See below. > If Hurd lacks accelerated 3D, it might make sense to only ship > ioquake3-server, and leave out ioquake3. Does it make any harm if the client is built? I don't think people will try the client until 3D video is supported. > > +ifeq ($(COMPILE_PLATFORM),gnu) > > + COMPILE_ARCH=x86 > > +endif > > This part is (or should be) unnecessary, and could break on hurd-* other > than hurd-i386. For some reason the ioquake3 build system refers to > "i386" and "x86_64" on Linux and kFreeBSD (and I think you should follow > this naming convention for Hurd too), but "x86" and "x64" on Windows. Yes, it is not needed, I have built ioquake3 without that part. Should I a provide an updated patch? > Because you patched the "Linux" case to pick up Hurd as well as Linux > and kFreeBSD, if you take this part out, the "Linux" logic should still > apply. (When upstream say Linux they really mean GNU/anything.) > > What does this: > > uname|sed -e s/_.*//|tr '[:upper:]' '[:lower:]'|sed -e 's/\//_/g' > > (used upstream to set COMPILE_PLATFORM) return on Hurd? Hopefully it's > "gnu". Yes, the answer is gnu because uname results in GNU. > We don't use this in Debian because we override it with > "debian/q3arch platform BUILD", but for the patch to be usable upstream, > they should return the same thing. (For instance, on Linux, q3arch has > to replace the linux-gnu from the GNU tuple with the linux that the > Makefile expects). OK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
