Technical support > Linux
Official Debian release for UFO:AI
apo:
Hi everyone,
I am a member of the Debian Games Team and I am working on an official release of UFO:AI for Debian and its derivatives. So far i'm trying to get the bigger picture by figuring out in how many packages the game has to be split and if there are any license issues to consider.
You have done an extraordinary job with documenting the licenses of each and every file of the game. From Debian's point of view there exist only two issues which i think are easily solvable.
All files that are licensed under CC-BY-SA-2.0 and CC-BY-SA-2.5 are considered non-free by Debian but clause 4b) of CC-BY-SA-2.5 grants the right to upgrade the license to a later version while CC-BY-SA-3.0 is considered to be a DFSG-free license. CC-BY-2.5 is even less restrictive (no copyleft) and upgrading to CC-BY-3.0 should be no problem at all.
I have tried to compile the stable version 2.4 but the game failed to build from source with the latest packages from Debian unstable.
--- Code: ---CamWnd.cpp:411: undefined reference to `CameraSettings::getMode() const'
--- End code ---
However the latest development version compiles fine. I have built upon the already available Debian packaging work but upgraded almost all files to more recent technologies like source format 3.0, dh sequencer and so on.
My questions (so far):
I intend to split the game data in multiple source packages, depending on the frequency of updates, because the data is very large. Which data files change regularly and what files are more static?
UFO:AI seems to depend on many different fonts. What fonts are strictly needed to make the game run? The current unofficial Debian packaging pulls in almost 150 MB of font data.
Why do you build-depend on binutils-dev? The game appears running fine without binutils.
Do you provide a changelog somewhere?
I think i will find more questions in the future but that's it for now. ;)
Thanks for reading this far and for developing UFO.
Markus
Mattn:
Hi and welcome to the board.
Great to hear this - our main goal for 2.5 was to get it into debian - 2.4 still contains a lot of invalid licensed stuff. I will check the licensing of the files as you said.
Btw. please also send the updates for to the debian files upstream.
We are delieving the game in pk3 files (zip files) and already group them in: music, maps, videos, scripts and so on (run make pk3 to see the pk3 files in base/). You would either have to skip this for the debian packages or are somehow tied to the pk3 structure/grouping.
As for new versions and updates - the maps and the ufo scripts should at least be packaged alone. If we have minor releases, this is almost always about map bugs, script bug/rebalancing or code bugs. So datawise, base/ufos/ base/maps/**.bsp should get two packages on their own.
for releasing patches we normally just offer a new pk3 file - the game always loads the pk3 files in alphabetical order and only loads the first file from it. That means that a pk3 file 0ufos.pk3 which contains e.g. ui.ufo and ui2.ufo can be overridden by a 1ufos.pk3 which brings a patched version of ui2.ufo - so ui.ufo is still used from 0ufos.pk3, ui2.ufo is used from 1ufos.pk3. I'm not sure how to deal with this in the debian way. An option would be of course to just create a new 0ufos.pk3 and update the ufo-scripts.deb or whatever you will call it.
I think we will do a cleanup of translations before we release 2.5 - because some are outdated and not yet updated for 2.5. and the fonts are only needed for e.g. the chinese translation.
we depend on binutils-dev because we do backtraces on crashes and upload them to our server - if you don't use binutils-dev (libbfd) for building the game - the backtrace feature is disabled automatically.
we will create a changelog for the final 2.5 version. we only provide changelogs for every official release - and we provide monthly changelogs in the news for the current dev builds.
getting this into debian would be a huge step for us - so big thanks for offering us this opportunity. and if you have any other question - just ask and i will do my best to answer it.
Mattn:
oh, btw. do you also plan to include uforadiant into debian? if yes, that would be awesome. but it would be even cooler to also get picomodel packages then - https://github.com/ufoai/picomodel
uforadiant is using this lib to load the models. it's also included in our codebase, but it should imo go into debian as well if you package uforadiant.
apo:
Hi Mattn,
--- Quote ---Great to hear this - our main goal for 2.5 was to get it into debian - 2.4 still contains a lot of invalid licensed stuff. I will check the licensing of the files as you said.
--- End quote ---
That would be great. If http://ufoai.org/licenses/ is up-to-date then there are no blockers anymore for an inclusion in Debian main. However i discovered license.txt in base/textures and it claims that there are still textures of unknown origin. If this file is outdated and all other information correct, i see no reason at the moment why UFO:AI can't be included in Debian.
--- Quote ---Btw. please also send the updates for to the debian files upstream.
--- End quote ---
I will always send all patches upstream as long as they are of general interest for others, i promise. :) Though please consider to remove the debian directory in your source packages as soon as an official version exist. Keeping it in your git repository is a sane default, though. I will create an initial git repository for the Debian package soon and everyone can follow the progress there.
Some best practices for upstreams are described here:
https://wiki.debian.org/UpstreamGuide
--- Quote ---I think we will do a cleanup of translations before we release 2.5 - because some are outdated and not yet updated for 2.5. and the fonts are only needed for e.g. the chinese translation.
--- End quote ---
Ok, i only need to know what fonts are essential to make the game work. I think it is sane to suggest all other ones (e.g. the chinese translation). I assume the dejavu- and free fonts are mandatory?
--- Quote ---we depend on binutils-dev because we do backtraces on crashes and upload them to our server - if you don't use binutils-dev (libbfd) for building the game - the backtrace feature is disabled automatically.
--- End quote ---
Allright, then i will omit binutils-dev and aim for an optimized release version only.
--- Quote ---we will create a changelog for the final 2.5 version. we only provide changelogs for every official release - and we provide monthly changelogs in the news for the current dev builds.
--- End quote ---
I saw your really nice monthly updates on the frontpage. I am only asking because it would be nice to include some kind of text file in the official release that documents all changes since the last version. Another option would be to convert the git commits to a changelog file. That's nice to have but not a big issue.
--- Quote ---oh, btw. do you also plan to include uforadiant into debian? if yes, that would be awesome. but it would be even cooler to also get picomodel packages then - https://github.com/ufoai/picomodel
--- End quote ---
Yes, I intend to package uforadiant as well. I don't know much about picomodel yet but if you think it is a valuable tool to enhance the game or to make developing of UFO:AI easier, I'm absolutely open for packaging it.
Here are my current thoughts how to split the game in multiple packages for ease of use.
Source package: ufoai
It builds those binary packages:
ufoai (game client)
ufoai-server (dedicated server)
ufoai-uforadiant (mapping tool)
ufoai-tools (ufo2map, ufomodel, ufoslicer)
ufoai-common (architecture-independent files which are shared between server and client, e.g. language files, documentation)
libufoai-game (the game.so shared library)
I am not sure about the last two binary packages. I only saw that a shared library called game.so is built and as far as I understand, it is required by both, client and server. Hence I think it would make sense to package the library in a single binary package and let client and server depend on it.
Game data:
I haven't found any information about required data packages for client and server yet. I presume the client will need all files under /base in the git repository to run correctly. My goal is to create a ufoai-server binary package that is similar to the existing openarena-server package in Debian. That means you can easily run the server with the help of an init script. Does the server require all data packages as well?
I intend to keep the .pk3 structure but i would like to build as much as possible from source. I had the following structure in mind:
Source package: ufoai-maps
It builds the binary package ufoai-maps.
All maps need to be compiled from source and they are quite large so i think they deserve a separate source package.
Source package: ufoai-music
It builds the binary package ufoai-music
Very simple package that only installs the music files to the right place. I would make ufoai-music a recommendation but not a strictly required dependency of ufoai.
Source package: ufoai-misc
It builds the binary package ufoai-misc.
Basically that would be everything else that is architecture-independent like textures, videos, scripts, pics, sounds and so on.
The reasoning behind the splitting is that nobody has to upload a 900 MB data package to the mirrors every time something changes.
Although the data is splitted in multiple source packages, it think it makes sense to keep the same pk3 files you are offering today. It was great, if we could use xz compression for the source and binary packages. Probably the zip format for pk3 files is mandatory, but i was thinking about compressing everything with xz (which saves a lot of bandwith) and to create zip compressed binary data packages in Debian's post-installation step. That means the user downloads xz compressed files and automatically runs a script that creates zip compressed pk3 files in the end.
Unfortunately the downside is that it might take several minutes to recompress the data on the user's pc. So obviously it would be better if we could ship xz compressed pk3 files right from the start. I assume that's easier said than done.
Mattn:
--- Quote from: apo on July 14, 2013, 08:35:04 pm ---That would be great. If http://ufoai.org/licenses/ is up-to-date then there are no blockers anymore for an inclusion in Debian main. However i discovered license.txt in base/textures and it claims that there are still textures of unknown origin. If this file is outdated and all other information correct, i see no reason at the moment why UFO:AI can't be included in Debian.
--- End quote ---
It's updated automatically by a cron job afair (long time since I touched this - but it's updated automatically in every case)
--- Quote ---Ok, i only need to know what fonts are essential to make the game work. I think it is sane to suggest all other ones (e.g. the chinese translation). I assume the dejavu- and free fonts are mandatory?
--- End quote ---
DejaVuSans.ttf is the only font that's needed for
--- Quote ---I saw your really nice monthly updates on the frontpage. I am only asking because it would be nice to include some kind of text file in the official release that documents all changes since the last version. Another option would be to convert the git commits to a changelog file. That's nice to have but not a big issue.
--- End quote ---
We will have such a list once 2.5 is officially released - when do you plan to publish the debian version? And you plan to do this on the 2.5 codebase, no? (just to be sure - 2.4 wouldn't work due to license restrictions - the license page is only valid for the master branch)
--- Quote ---Yes, I intend to package uforadiant as well. I don't know much about picomodel yet but if you think it is a valuable tool to enhance the game or to make developing of UFO:AI easier, I'm absolutely open for packaging it.
--- End quote ---
that would be nice and i totally agree that it makes modding easier - and maybe we can attract some more mappers this way ;)
--- Quote ---Here are my current thoughts how to split the game in multiple packages for ease of use.
[...]
--- End quote ---
Makes sense - but you can also decide to hardlink the game.so (./configure --enable-hardlinkedgame) then libufoai-game would not be needed. And in case of a patch it's unlikely that the ufo or ufoded binaries are not updated, too. But this is up to you. And yes - game.so is loaded whereever the server runs - if it's a listen server, then the ufo loads the game.so - if it's a dedicated server, then ufoded loads the game.so
--- Quote ---Game data:
I haven't found any information about required data packages for client and server yet. I presume the client will need all files under /base in the git repository to run correctly. My goal is to create a ufoai-server binary package that is similar to the existing openarena-server package in Debian. That means you can easily run the server with the help of an init script. Does the server require all data packages as well?
--- End quote ---
Well - to be executed the server does not need the music, pics, sounds and so on - but... the server can also be configured in a way to offer these files as downloads for clients that don't have one particular file. I don't think this will ever happen - but well... it's a feature. And new user created content would be available on the server anyway. But to be honest i've never tried to run the server on a minimal dataset.
--- Quote ---I intend to keep the .pk3 structure but i would like to build as much as possible from source. I had the following structure in mind:
Source package: ufoai-maps
It builds the binary package ufoai-maps.
All maps need to be compiled from source and they are quite large so i think they deserve a separate source package.
Source package: ufoai-music
--- End quote ---
Please don't bulid the maps from source - please use those that we deliever when we release 2.5 officially. The problem here is floating point stuff. You would make cross plattform multiplayer stuff impossible because the checksum is different on different architectures. If you plan to release before we official release 2.5, please use the maps-sync script (make maps-sync)
--- Quote ---Although the data is splitted in multiple source packages, it think it makes sense to keep the same pk3 files you are offering today. It was great, if we could use xz compression for the source and binary packages. Probably the zip format for pk3 files is mandatory, but i was thinking about compressing everything with xz (which saves a lot of bandwith) and to create zip compressed binary data packages in Debian's post-installation step. That means the user downloads xz compressed files and automatically runs a script that creates zip compressed pk3 files in the end.
Unfortunately the downside is that it might take several minutes to recompress the data on the user's pc. So obviously it would be better if we could ship xz compressed pk3 files right from the start. I assume that's easier said than done.
--- End quote ---
I think we once used 7zip to create the pk3 files and had no problems with it - so go for it. I don't think one has to convert them.
Martin
Navigation
[0] Message Index
[#] Next page
Go to full version