Hi David, On 06.11.2014 19:14, David Bate wrote: [...] >> David Bate and Simon McVittie did some initial work on it but this game >> definitely needs a dedicated maintainer. I would also contribute to the >> packaging if there was a real driver. > > Yes, I have been very dormant on this lately. Sorry about this. > > It would be great to great to have a new effort to package Xonotic. I > am perfectly happy keeping darkplaces (the engine that Xonotic uses) up > to date and also other pieces of the puzzle or organising the general > direction - but everything together was overwhelming for me. > > The problem is that I went too far down the rabbit hole... > > Packaging the data for Xonotic (from source) is fairly easy for the most > part: the upstream build system uses a single script that compiles the > images. Invoking this through find should be enough. It would be nice if we had some kind of TODO list for Xonotic. Something like an overview that shows what source packages are needed for Xonotic, links to the upstream sources and comments what has to be done. I would suggest to build a rough version of Xonotic first, solve the most important technical issues to make the game run and then optimize the packaging as far as this is possible and required. Whether puzzle pieces such as d0_blind_id can be replaced by another library should be decided later when we have figured out the bigger picture. Could you create such a TODO list and assemble all the information for a dedicated wiki page or post it to this mailing list? > The problem is with maps. Upstream maintains the netradiant level > editor: > > http://git.xonotic.org/?p=xonotic/netradiant.git > > and it includes a map compiler q3map2. I initially looked at packaging > this but the licensing of many files is in a bad state. For example > there are GPL 2+ files that are also under a limited use license from ID > software. This license is not included in the source, but searching > online for possible candidates reveals that it is not GPL compatible. > > However, a similar project, GtkRadiant, is maintained by a former > employee of ID software and it contains the same files but the > references to the ID License have been removed, so maybe permission was > granted to remove them. This would need investigation. I am not sure whether we need netradiant at all because ufoai contains uforadiant which is based on GtkRadiant, a completely free and GPLed version and which is probably capable of editing maps for Xonotic as well. The question is do we need q3map2 for compiling netradiant, the map editor, or Xonotic itself? Currently our handling of compiling maps is not consistent and differs from game to game. AFAIK Openarena uses pre-compiled maps because otherwise it would be impossible to join "pure" servers that require pristine maps for anti-cheat measures. All Quake-based games are affected. Due to slightly different floating-point arithmetics the map compilation results always differ. I have also talked with the upstream developers of UFO:AI about that issue and in this case they decided to remove the check for pristine maps, so I could build the maps from source without making the game unplayable. Of course this decision could only be made because anti-cheat measures for ufoai's multiplayer mode are not crucial. > I have to admit, I got to this point and gave up. I think that it would > require some serious effort to make this ready for Debian. I believe > that there were other license issues too. If someone would like to try > packaging it I can write up my findings in a more helpful way. A status page / TODO list would be fine. Actually I can't imagine that Xonotic is very different from Nexuiz. It would be surprising if there was a serious blocker along the road. > Looking forward, if we want to get Xonotic into Debian (which I think > would be excellent) we have to solve this problem. I can see a few > possible solutions, maybe other members of the team can think of others: > > * We actually package netradiant (seems difficult). Let's postpone this decision until uforadiant is available. > * We may be able to use a different Quake map compiler that is in a > better shape, for example ufo-radiant or get GtkRadiant to compile > Xonotic maps (if GtkRadiant is in a better shape). I do not know of > the chances that this will work, but it may be worth investigating to > save us duplicated effort. Just for clarification: uforadiant is the map editor. UFO:AI ships a dedicated tool called »ufo2map«, packaged in ufoai-tools, that is responsible for compiling the maps from scratch. > * We package the maps (and maybe other assets) that are compiled by > upstream. Of course, this is not the most desirable solution, but > something is better than nothing. This is how the data for Nexuiz is > packaged. I am not sure if Debian's opinion on doing this changes > under the condition that there does/may not *exist* a compiler > suitable for Debian (rather than it not being *packaged* for Debian, as > I believe was the understanding for Nexuiz). As I have already pointed out, it might be even impossible to join servers if we packaged different maps for Xonotic. If it is suitable for Nexuiz, I'm sure it is suitable for Xonotic too but we should investigate how they compile the maps and how we could reuse the packaging from Nexuiz. It should be sufficient to add an option to compile the maps from scratch for those who'd like to. I don't understand why Xonotic would use a non-free map compiler though. That needs more investigation. > Are there any opinions on this? I hope that we can get something > working. TODO list -> Basic packaging, make it work -> optimizations Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature