Debian Bug report logs - #679330
ioquake3: Add support for GNU/Hurd

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Debian bug reporting <submit@bugs.debian.org>

Subject: ioquake3: Add support for GNU/Hurd

Date: Thu, 28 Jun 2012 00:10:18 +0200

[Message part 1 (text/plain, inline)]

Source: ioquake3
Version: 1.36+svn2287
Severity: normal
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello, ioquake3 FTBFS for GNU/Hurd due to a lack of support for this OS:
#error "Operating system not supported", see
https://buildd.debian.org/status/fetch.php?pkg=ioquake3&arch=hurd-i386&ver=1.36%2Bsvn1946-5&stamp=1312459705

The attached patch adds support for the GNU/Hurd architecture by
changing the debian/control, Makefile and code/qcommon/q_platform.h
files. Please apply it whenever convenient for you.

Thanks!

[hurd_support.patch (text/x-patch, attachment)]

Message #10 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: svante.signell@telia.com, 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Thu, 28 Jun 2012 09:03:13 +0100

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?

To test it, you'll need a very similar patch for openarena (the build
system is almost identical). You could also use Quake III Arena if you
own a copy, 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)
* 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)
* 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)

If Hurd lacks accelerated 3D, it might make sense to only ship
ioquake3-server, and leave out ioquake3.

> +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.

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". 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).

    S

Message #15 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Thu, 28 Jun 2012 23:25:54 +0200

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.

Message #20 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: svante.signell@telia.com, 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Fri, 29 Jun 2012 10:03:50 +0100

On 28/06/12 22:25, Svante Signell wrote:
> 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

> I have now patched and built openarena. Care for a new bug report?

If you want another bug number, but sending the openarena patch to this
one is probably easier.

>> You could also use Quake III Arena
> 
> Yes, I happen to have one. Don't know what to install from the CD
> though, the pak0.pk3?? file and ?

pak0.pk3 is all you need from the CD. You also need the last Quake III
Arena patch (install quake3 and look in
/usr/share/games/quake3/README.quake3-data for more details). Then run:

    game-data-packager /path/to/pak0.pk3 \
        /path/to/linuxq3apoint-1.32b-3.x86.run

and install the resulting quake3-data package.

As I said, OpenArena is a better test, though (it exercises bits of the
code that aren't normally used in Quake III Arena, and that I suspect
could be a problem on new ports).

>> * 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?

The client (in any game of this genre).

>> 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.

I'd prefer to avoid shipping a package that's effectively useless on its
target OS, particularly if that means nobody has ever tested it.

libgl1-mesa-swx11 might be less horribly slow than an unaccelerated
libgl1-mesa-glx, perhaps? The state-of-the-art in software rendering is
llvmpipe, but Debian doesn't seem to have that yet.

> Yes, it is not needed, I have built ioquake3 without that part. Should I
> a provide an updated patch?

Just to be sure, please send the actual patches you tested.

> Yes, the answer is gnu because uname results in GNU.

Good, the patch should be able to go upstream then.

    S

Message #25 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Fri, 29 Jun 2012 17:26:07 +0200

[Message part 1 (text/plain, inline)]

On Fri, 2012-06-29 at 10:03 +0100, Simon McVittie wrote:
> On 28/06/12 22:25, Svante Signell wrote:
> > 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
> 
> > I have now patched and built openarena. Care for a new bug report?
> 
> If you want another bug number, but sending the openarena patch to this
> one is probably easier.

Attaching the openarena patch.

> >> You could also use Quake III Arena

Thanks, will try that later.

> As I said, OpenArena is a better test, though (it exercises bits of the
> code that aren't normally used in Quake III Arena, and that I suspect
> could be a problem on new ports).

Will try that first, but maybe not until after the week-end.

> >> 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.
> 
> I'd prefer to avoid shipping a package that's effectively useless on its
> target OS, particularly if that means nobody has ever tested it.

I will test it, see above and below. As you might know a lot of packages
build for GNU/Hurd without kernel support yet, like audio packages.

> libgl1-mesa-swx11 might be less horribly slow than an unaccelerated
> libgl1-mesa-glx, perhaps? The state-of-the-art in software rendering is
> llvmpipe, but Debian doesn't seem to have that yet.

Looks like llvmpipe is supported in mesa for Linux/kFreeBSD i386/amd64.
Not yet for Hurd, I will try it to enable it, llvm is available for
Hurd! And also try with libgl1-mesa-swx11.

> > Yes, it is not needed, I have built ioquake3 without that part. Should I
> > a provide an updated patch?
> 
> Just to be sure, please send the actual patches you tested.

Updated patch applied!

> > Yes, the answer is gnu because uname results in GNU.
> 
> Good, the patch should be able to go upstream then.

Nice!

[openarena_hurd_support.patch (text/x-patch, attachment)]

[ioquake3_hurd_support.patch (text/x-patch, attachment)]

Message #30 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <fabian@greffrath.com>

To: Svante Signell <svante.signell@telia.com>, 679330@bugs.debian.org

Cc: Simon McVittie <smcv@debian.org>

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Fri, 29 Jun 2012 21:37:18 +0200

> -Architecture: linux-any kfreebsd-any
> +Architecture: linux-any kfreebsd-any hurd-any

Wouldn't this simply be "any" then?

Message #35 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Fabian Greffrath <fabian@greffrath.com>, 679330@bugs.debian.org

Cc: Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Sat, 30 Jun 2012 14:21:41 +0100

On 29/06/12 20:37, Fabian Greffrath wrote:
> 
>> -Architecture: linux-any kfreebsd-any
>> +Architecture: linux-any kfreebsd-any hurd-any
> 
> Wouldn't this simply be "any" then?

I'd be inclined to say no: the Quake 3 engine has a "list of known
systems" approach to porting, so if Debian is ported to yet another
kernel (GNU/kNetBSD? GNU/kSolaris?) it's very likely to not compile
there without a patch similar to the one Svante did for Hurd.

(It also does things like networking and plugin-loading at a
sufficiently low level that if it compiles on a particular kernel/libc
combination, it's not necessarily true that it *works* there, so it's
valuable to confirm that it does really work before allowing it to be
autobuilt.)

    S

Message #40 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <fabian@greffrath.com>

To: Simon McVittie <smcv@debian.org>

Cc: 679330@bugs.debian.org, Svante Signell <svante.signell@telia.com>

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Mon, 02 Jul 2012 09:03:30 +0200

Am 30.06.2012 15:21, schrieb Simon McVittie:
> I'd be inclined to say no: the Quake 3 engine has a "list of known
> systems" approach to porting, so if Debian is ported to yet another
> kernel (GNU/kNetBSD? GNU/kSolaris?) it's very likely to not compile
> there without a patch similar to the one Svante did for Hurd.

This is getting OT, But I'd say this applies to nearly all software in 
Debian. IMHO if the Architecture field is set to "any" than the 
package is *targeted* at any architecture, i.e. there is no reason 
that speaks against attempting to build on all architectures. It does 
not mean, in turn, that it is actually tested or even expected to run 
on e.g. knetbsd-s390x. ;)

 - Fabian

Message #45 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 679330@bugs.debian.org, 671014@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Wed, 04 Jul 2012 00:49:31 +0200

On Fri, 2012-06-29 at 17:26 +0200, Svante Signell wrote:
> On Fri, 2012-06-29 at 10:03 +0100, Simon McVittie wrote:
> > On 28/06/12 22:25, Svante Signell wrote:
> > > 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
...
> > As I said, OpenArena is a better test, though (it exercises bits of the
> > code that aren't normally used in Quake III Arena, and that I suspect
> > could be a problem on new ports).
> 
> Will try that first, but maybe not until after the week-end.

I have now tried openarena and it runs OK at 400x300 with the mesa-swx11
driver. Will try further with llvmpipe, at least it builds :)

The only error printout is: Com_QueueEvent: overflow (whatever it means,
only happening at higher resolutions) 

> > >> 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.

See above, 400x300 is OK, and lower resolutions even better.

Another issue: Quake1/2? runs perfectly in 400x300. Please add __GNU__
to Quake/net_sys.h in the quakespasm package, please, see bug #671014

Message #50 received at 679330-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 679330-close@bugs.debian.org

Subject: Bug#679330: fixed in ioquake3 1.36+svn2287-2

Date: Thu, 05 Jul 2012 09:17:14 +0000

Source: ioquake3
Source-Version: 1.36+svn2287-2

We believe that the bug you reported is fixed in the latest version of
ioquake3, which is due to be installed in the Debian FTP archive:

ioquake3-dbg_1.36+svn2287-2_amd64.deb
  to main/i/ioquake3/ioquake3-dbg_1.36+svn2287-2_amd64.deb
ioquake3-server_1.36+svn2287-2_amd64.deb
  to main/i/ioquake3/ioquake3-server_1.36+svn2287-2_amd64.deb
ioquake3_1.36+svn2287-2.debian.tar.gz
  to main/i/ioquake3/ioquake3_1.36+svn2287-2.debian.tar.gz
ioquake3_1.36+svn2287-2.dsc
  to main/i/ioquake3/ioquake3_1.36+svn2287-2.dsc
ioquake3_1.36+svn2287-2_amd64.deb
  to main/i/ioquake3/ioquake3_1.36+svn2287-2_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 679330@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated ioquake3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 05 Jul 2012 08:57:53 +0100
Source: ioquake3
Binary: ioquake3 ioquake3-server ioquake3-dbg
Architecture: source amd64
Version: 1.36+svn2287-2
Distribution: experimental
Urgency: low
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description: 
 ioquake3   - Game engine for 3D first person shooter games
 ioquake3-dbg - debug symbols for the ioquake3 game engine
 ioquake3-server - Standalone server for ioQuake3 based games
Closes: 679330
Changes: 
 ioquake3 (1.36+svn2287-2) experimental; urgency=low
 .
   * Adjust gbp.conf for experimental
   * Compile on Hurd, treating it like Linux and kFreeBSD (patch and testing
     by Svante Signell, closes: #679330)
Checksums-Sha1: 
 49af7d8abb159f6440517074fc965c91f44f368e 2205 ioquake3_1.36+svn2287-2.dsc
 b7264d09ebcc809413478269920b445a58226a53 19087 ioquake3_1.36+svn2287-2.debian.tar.gz
 d255dd6da3080ff30ba3722b651938e0a74c1ebb 1891852 ioquake3_1.36+svn2287-2_amd64.deb
 b1a530577f917c4ab9c1c317665c889ed5871a05 1140638 ioquake3-server_1.36+svn2287-2_amd64.deb
 105aaaa3cd7d1cc791b336aeebbe5316f25c85e6 5240666 ioquake3-dbg_1.36+svn2287-2_amd64.deb
Checksums-Sha256: 
 d0efe33634828e7d16add30fb526f230438682be1c81365910709e78773f13c7 2205 ioquake3_1.36+svn2287-2.dsc
 872312c4bc712b82eec7046a66dbceb099a405da58c3ea9586fb9cf03ac0fdce 19087 ioquake3_1.36+svn2287-2.debian.tar.gz
 91ab667a782dcb85a80edf1be9e5a4962317085440482fd1b0a4f7683264b15f 1891852 ioquake3_1.36+svn2287-2_amd64.deb
 80140529ff1a349a42fa5547aad7a4ab2707023ea64d7d5e4700684c7f2995a9 1140638 ioquake3-server_1.36+svn2287-2_amd64.deb
 f429fca4cf6102d203749fecc8924706a134ba64c820da9c5f43ebefb19d2107 5240666 ioquake3-dbg_1.36+svn2287-2_amd64.deb
Files: 
 fdf3c3514ce65cd1ce46b129f69cf418 2205 games optional ioquake3_1.36+svn2287-2.dsc
 2fd167e8b64788abd0584fabd8f1d5ed 19087 games optional ioquake3_1.36+svn2287-2.debian.tar.gz
 79fd7a11cbbaa33a836ba480cf8ca0b1 1891852 games optional ioquake3_1.36+svn2287-2_amd64.deb
 09bf509c1899864d032da391680d01a9 1140638 games optional ioquake3-server_1.36+svn2287-2_amd64.deb
 b9aa9926c43f334a77685df3bd2fe8ae 5240666 debug extra ioquake3-dbg_1.36+svn2287-2_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIVAwUBT/VYNU3o/ypjx8yQAQgp/xAAnq4y2M0lmapEUKPVQ7CsjM9ewvdTzd2c
KaBmfLm1DgrZC5DOeS/cp0LFUZ99MvcVkArY9fn7rCEZep4p674IACjuQF33ZHJl
zF1SOWs5YTHqaSf+zvpHynfKyyOEokRX2MVeNQO0icJ6h3yK/m4MOLL72I9iosOK
2QigBb4vgHPMNp46HbiI8MCc5ICfbIP7fH3K8rH5aKuQXblh9zKiaXfqAsLVA78s
LnSyx7PIvB3stiuLLmjUUAb/sE5zpMPEtl8I7kv0eKe43iA0P6b8VrO1lzdtj3Uu
qTUzD+J30SqA1NM4oCEMoiKiZL2GV2imm8B7abBZmaRZJEGax8VgVrNRQyaH2ObX
dtVmtzFOj6l/1V05o0Bz9/swi6fw8+zsqfkOvze5c8tu0GEbJWgPAh7adZxVdL+W
XZAdAodAXF9Qdk5egqgCiHMmkAL4n1WXoRgaxSNUaW+PK2VDfFszlGBG4eFl4a6E
LQfAX2IOyJimj0aqwWO57eikyF5iBFQtNsnag0cudohPw642DgvU/wn54AR+EwtU
VqmZDjBvxw6c7m4gVTrwkMR/Y9DA+7jNh4CP2WPiZ43zz97ru5BgV+ackUN3VKpV
qJOrXeCKXDp049VDvC/BdvEZnY02YIjEppwuAJbcl+FCTqGbXt6L4a/nfsymO8Tn
+siWisXrk40=
=hsa/
-----END PGP SIGNATURE-----

Message #55 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: svante.signell@telia.com, 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Thu, 05 Jul 2012 11:37:48 +0100

On 03/07/12 23:49, Svante Signell wrote:
> I have now tried openarena and it runs OK at 400x300 with the mesa-swx11
> driver. Will try further with llvmpipe, at least it builds :)

I've uploaded ioquake3 and openarena to experimental (would be unstable,
but there's a freeze on), with both client and server enabled on Hurd.

As far as I can see, this doesn't meet the criteria for a freeze
exception, so I'm not going to request one. If you disagree and want
this change to get to unstable, feel free to request a freeze exception
yourself; if you get one, I'd be happy to upload the same changes to
unstable. The debdiff would be the same as in experimental, but with the
debian/gbp.conf change reverted, and a trivial new changelog entry.

> The only error printout is: Com_QueueEvent: overflow (whatever it means,
> only happening at higher resolutions) 

I think that means "your framerate is too low for the engine's
assumptions to be true", so you can expect it to happen with
unaccelerated 3D, particularly at higher resolutions.

If I understand correctly, the Quake III engine puts incoming input and
network events in a fixed-length queue, and processes them as a batch
between rendered frames - if too much time passes between frames, then
new events won't fit in the queue and are dropped. Changing the
cl_renderer cvar from opengl1 to opengl1_smp ("\set cl_renderer
opengl1_smp" in the Quake III console) might help, if you have a second
CPU where you can do the rendering.

> Another issue: Quake1/2? runs perfectly in 400x300. Please add __GNU__
> to Quake/net_sys.h in the quakespasm package, please, see bug #671014

Also uploaded, sorry for the delay. I'd prefer to fix this properly (by
using struct sockaddr, rather than reconstructing it from incomplete
knowledge of the OS), but this will have to do for now.

    S

Message #60 received at 679330@bugs.debian.org (full text, mbox, reply):

From: Svante Signell <svante.signell@telia.com>

To: Simon McVittie <smcv@debian.org>

Cc: 679330@bugs.debian.org

Subject: Re: Bug#679330: ioquake3: Add support for GNU/Hurd

Date: Thu, 05 Jul 2012 17:24:27 +0200

On Thu, 2012-07-05 at 11:37 +0100, Simon McVittie wrote:
> On 03/07/12 23:49, Svante Signell wrote:
> > I have now tried openarena and it runs OK at 400x300 with the mesa-swx11
> > driver. Will try further with llvmpipe, at least it builds :)
> 
> I've uploaded ioquake3 and openarena to experimental (would be unstable,
> but there's a freeze on), with both client and server enabled on Hurd.

Thanks a lot! I have not found any improvement by enabling llvmpipe
when building mesa. Have to dig a little deeper before knowing more.
Switching from glx to swx11 doubled the speed of glxgears. Will also try
with the Hurd server and Linux client (in due time).

> As far as I can see, this doesn't meet the criteria for a freeze
> exception, so I'm not going to request one. If you disagree and want
> this change to get to unstable, feel free to request a freeze exception
> yourself; if you get one, I'd be happy to upload the same changes to
> unstable. The debdiff would be the same as in experimental, but with the
> debian/gbp.conf change reverted, and a trivial new changelog entry.

I don't think a freeze exception is needed right now. Will do that if
requested by somebody else later on.

> > The only error printout is: Com_QueueEvent: overflow (whatever it means,
> > only happening at higher resolutions) 
> 
> I think that means "your framerate is too low for the engine's
> assumptions to be true", so you can expect it to happen with
> unaccelerated 3D, particularly at higher resolutions.

OK!

> > Another issue: Quake1/2? runs perfectly in 400x300. Please add __GNU__
> > to Quake/net_sys.h in the quakespasm package, please, see bug #671014
> 
> Also uploaded, sorry for the delay. I'd prefer to fix this properly (by
> using struct sockaddr, rather than reconstructing it from incomplete
> knowledge of the OS), but this will have to do for now.

Thanks!

Send a report that this bug log contains spam.