On Sat, 08. Nov 16:59 Simon McVittie <smcv@debian.org> wrote: > On 08/11/14 15:20, Markus Koschany wrote: > > 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. > > I believe we have working packaging for (maybe an old-ish version of) > d0_blind_id which is technically ready for upload; but I don't want to > sponsor its upload until someone can test it in a useful way, which in > practice means having a rough version of Xonotic running. Xonotic does > not have to be perfectly ready for that to happen; for instance, a > version that uses precompiled assets would certainly be fine. Fair enough. Was there any kind of preliminary work for Xonotic, preferably maintained in a Vcs? I guess I could prepare a new version of Xonotic 0.7, just the game, provided the current d0-blind-id packaging is still sufficient for building it. We should update darkplaces and d0-blind-id then in a subsequent step. > I don't really play multiplayer-only games, so I am not going to > maintain Xonotic, but I'm happy to help with it from the darkplaces > angle. That's a good start. I don't intend to become the sole maintainer of Xonotic, too, but I am willing to support as many good free software games and tools in Debian as possible. Packaging shouldn't be that hard since we can learn from similar fps games in the archive. However interacting with bug reporters, forwarding bugs and patches upstream and preparing new upstream releases takes time, so obviously the more people help, the better. (*broad hint for all anonymous readers of this list*) ;) > At some point I should probably package the 20140513 upstream > release of darkplaces for experimental - what do Xonotic people think > about that version? Is it good? Is there a nearby svn commit that I > should be using instead, or a set of patches for errata that should be > applied? I don't know yet. That's probably a question for upstream. [...] > Of course, having automated builds for as many of the assets as possible > is a nice thing to have, and a perfectly reasonable feature request for > your upstream; but I don't think its absence prevents those assets from > being included in Debian, as long as they are, or are accompanied by, > the form you would usually modify. Agreed. UFO:AI is in many aspects very different from OpenArena. In this case it is unlikely that people will complain about the lack of identical maps across different operating systems. I just felt that upstream did a great job in providing the necessary tools and build systems, so I split the maps and textures into a separate package and built them from source. > > 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. > > If your upstream is willing to do that, great. If not, I don't think > that should be considered to be release-critical. My last RC bug against Openarena was two years ago, I guess it's time... > > I don't > > understand why Xonotic would use a non-free map compiler though. > > Because it's there, and/or because the upstream developers don't > consider a complete and self-contained Free toolchain to be as important > as their own content being Free. No, I meant it's somehow weird because q3map2 is part of GtkRadiant which in turn is GPL licensed. So how can it be non-free? https://github.com/TTimo/GtkRadiant I believe it's time to have a closer look at those licenses. Regards, Markus
Attachment:
signature.asc
Description: Digital signature