Am Samstag, den 23.01.2010, 18:52 +0100 schrieb Hans de Goede: > Hi, > > On 01/22/2010 08:08 AM, Paul Wise wrote: > > On Wed, Jan 20, 2010 at 11:33 AM, Simon McVittie<smcv@debian.org> wrote: > > > >> I've attached patches to bugs on openarena and openarena-data to address the > >> issue of sourceless QVMs (bytecode files) in openarena-data (not only do we > >> not distribute source, but they need a non-free compiler). However, I don't > >> feel that I should upload such major changes without review from someone who > >> knows this codebase better, so I haven't done an NMU or games-team upload > >> (since working on those bugs I've joined the games team to work on > >> game-data-packager). Could someone have a look, please? > >> > >> It'd also be great if someone who is in touch with upstream could talk to them > >> about this, as it'll probably continue to be a problem in future. > > > > I imagine that would be goneri and or fuddl? Probably best to fix this > > upstream first anyway. > > > >> In the long term, it'd be good if OpenArena could use a shared ioquake3 source > >> package (perhaps with multiple differently-patched or differently-configured > >> builds like linux-2.6, to allow for OpenArena changes?), so we could have > >> ioquake3 (engine-only support package in /usr/lib/ioquake3), openarena > >> (wrapper scripts, .desktop etc.) and openarena-data in main, quake3 (wrapper > >> scripts etc.) in contrib, and quake3-data non-distributable but produced on > >> users' systems using game-data-packager. > > > > I'd say openarena/quake3 could just contain the data, desktop file, > > wrapper script etc, no need for openarena-data or quake3-data. > > > >> Ideally, we could then ship World of Padman and/or Urban Terror on a similar > >> basis (patched or unpatched ioquake3 in contrib or main for the engine, > >> wrapper scripts in contrib, art and other data in non-free). > > > > I imagine most of these have forked the engine, probably significantly? > > > > No, in Fedora we use a single ioquake3 engine for quake3, openarena, word of > padman (wop) and urban terror. > > There all some small patches in there for this, but nothing big, and we set some > options when starting the engine in the wrapper script, see: > http://cvs.fedoraproject.org/viewvc/devel/quake3/ > > Basically all patches except 2 are for making this possible (and making the > shareware data files work without the binary spitting out various complaints). > > The 2 exceptions are: > > quake3-1.34-syslibs.patch: > Make the engine use the system libjpeg, I've tried getting this upstream but they > have denied it. You probably want this too, as otherwise the next libjpeg > security hole which pops up will need separate patching in your quake3 packages > > quake3-1.36-botlib-strcpy-abuse.patch: > A bugfix for some lets use strcpy when we want memmove issues, which get triggered > by using a new gcc or glibc (dunno which one on Fedora everything is always pretty > new). This patch is already upstream. > > > While on this subject, you may want to take a look at autodownloader just for fun, > download a livecd (and boot from it), do "yum install urbanterror" and then select > urbanterror in the application menu (under games, duh), or just start the wrapper > script from a terminal. This is our solution to what I guess you are doing > with game-data-packager. Note that this just downloads the files (and extracts them) > to ~/.q3a/<path>/, which means no root rights are needed, if you have > multiple users on the machine who all want these games it is very bandwidth and > diskspace inefficient, but we (I'm) are counting on that being the exception. Hi Hans, I had a look at your patches in Fedora and was wondering if you have something working or if you're working on something to get rid of the proprietary LCC compiler to build the QVM byte-code files. Or is there any other progress I don't know about? I've finished my diploma thesis, so I've probably missed a lot within the last few months ;) Cheers - Fuddl
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil