Technical support > Linux
Official Debian release for UFO:AI
apo:
Hi,
I have created an initial, unfinished, git repo for the UFO:AI packaging. http://anonscm.debian.org/gitweb/?p=pkg-games/ufoai.git
At the moment it covers only the binaries and the data packages are the next goal.
--- Quote ---DejaVuSans.ttf is the only font that's needed for
--- End quote ---
Thanks. languages.ttf is the other required font file otherwise the game won't start up.
--- Quote ---when do you plan to publish the debian version? And you plan to do this on the 2.5 codebase, no?
--- End quote ---
At the moment I'm working with the latest code from git, 2.5-dev. There isn't any fixed date for a Debian release. I suggest we take our time to create proper Debian packages and let others comment on our efforts. I assume everything could be working at the end of summer. Then it will take another few weeks to get the packages into Debian because they need to be checked by our ftp-masters.
--- Quote ---Makes sense - but you can also decide to hardlink the game.so (./configure --enable-hardlinkedgame) then libufoai-game would not be needed.
--- End quote ---
That was a good idea. I have done that.
--- 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.
--- End quote ---
That means the ufoai-server package does not need to depend on data packages to make it useful as long as the client depends on all data packages?
UFO:AI is very similar to OpenArena, thanks to the underlying Quake technology. However the openarena-server depends on data packages to enforce compatibility in case the player uses an older version (a new pak file will be automatically downloaded). I think we should discuss the desirable behaviour later, if i also know more about a sane default (system-wide) server configuration.
--- 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)
--- End quote ---
That is easier said than done. I understand that it is more work for me to build the maps from source and that we have to be careful to ensure that the pk3 files are identical to the official ones. The ability to build everything from source with tools in Debian main is a requirement for software to be included in Debian. We simply need to make sure that the build process is reproducable on the official release architecture. The maps themselves are architecture-independent, that means they are only built once on my local (amd64) pc. I just have to make sure that the package matches your official release.
The OpenArena maintainer has done a similar job in the past.
anonscm.debian.org/gitweb/?p=pkg-games/openarena-data.git
The binaries could avoid some useless dependencies if they weren't linked against certain libraries. I am attaching my build log which illustrates the problem. (It is one of the last build steps at the end, dpkg-shlibdeps) I think this could be optimized somehow.
I am now going to learn more about creating the data packages.
Edit:
If i use p7zip aka 7z to compress the pk3 files, ufo is no longer able to detect them. The default compression algorithm is lzma. Zip compression works well with p7zip-full and zip. Is there an option to make ufoai detect those lzma compressed pk3 packages somehow? Otherwise there wouldn't be any advantage in switching to p7zip.
Mattn:
--- Quote from: apo on July 19, 2013, 12:06:39 pm ---Thanks. languages.ttf is the other required font file otherwise the game won't start up.
--- End quote ---
yes - but that one for sure isn't in debian repos ;)
--- Quote ---That means the ufoai-server package does not need to depend on data packages to make it useful as long as the client depends on all data packages?
--- End quote ---
It still needs the maps and scripts of course - but other stuff.... I would have to test that, too. There might be a few files that are still needed besides that (motd, some configs)
--- Quote ---If i use p7zip aka 7z to compress the pk3 files, ufo is no longer able to detect them. The default compression algorithm is lzma. Zip compression works well with p7zip-full and zip. Is there an option to make ufoai detect those lzma compressed pk3 packages somehow? Otherwise there wouldn't be any advantage in switching to p7zip.
--- End quote ---
Strange, last time i checked it worked fine. I will have to recheck someday. There is no special flag to set. If it doesn't work out of the box... well - it doesn't work ;) Sorry for that.
Sandro:
Currently, UFO:AI supports only ZIP/DEFLATE as the compression algorithm. Adding support for LZMA could be a good idea, since it will give better compression for maps and models, but do we have a manpower for that?
apo:
Hi
I have updated the ufoai packaging at http://anonscm.debian.org/gitweb/?p=pkg-games/ufoai.git
and also created two new git repositories for the ufoai-data and ufoai-music source packages.
http://anonscm.debian.org/gitweb/?p=pkg-games/ufoai-data.git
http://anonscm.debian.org/gitweb/?p=pkg-games/ufoai-music.git
So far only ufoai-maps is missing and I'm using the precompiled maps for testing purposes at the moment.
I have filed a bug report for a reproducible segfault that seems to be triggered by the sound system (probably sdl_mixer). So far I couldn't find a solution
http://ufoai.org/bugs/ufoalieninvasion/issues/5072
--- Quote ---yes - but that one for sure isn't in debian repos
--- End quote ---
The question is, is languages.ttf something which is worth packaging separately? Normally fonts deserve a separate package because they might be useful for other software too. If that's not the case here, I suggest shipping the font with ufoai itself.
--- Quote ---Currently, UFO:AI supports only ZIP/DEFLATE as the compression algorithm. Adding support for LZMA could be a good idea, since it will give better compression for maps and models, but do we have a manpower for that?
--- End quote ---
Yes, that would be great.
I have packaged all data in pk3 files for 2.5-dev and in total it takes up 1,2 GB disk space. 0music.pk3 and 0sound.pk3 are already highly compressed ogg files. Even lzma wouldn't improve the situation here. You can gain the most by compressing maps, textures and pictures with a better compression algorithm which will approximately save up to 150 MB.
I will open new threads for specific packaging issues because I think it will be more effective to follow them separately.
Outstanding points so far:
- Compiling the maps and producing a version that is identical to the official UFO:AI release.
- dedicated server: creating a system-wide server installation.
- picomodel: standalone package or integrated into ufoai?
- license audit.
Mattn:
--- Quote from: apo on July 31, 2013, 02:54:57 pm ---I have filed a bug report for a reproducible segfault that seems to be triggered by the sound system (probably sdl_mixer). So far I couldn't find a solution
http://ufoai.org/bugs/ufoalieninvasion/issues/5072
--- End quote ---
I will have a look as soon as possible.
--- Quote --- The question is, is languages.ttf something which is worth packaging separately? Normally fonts deserve a separate package because they might be useful for other software too. If that's not the case here, I suggest shipping the font with ufoai itself.
--- End quote ---
This font is not useful for anything else than ufoai. So yes, ship it with ufoai, no separate package is needed.
--- Quote ---- picomodel: standalone package or integrated into ufoai?
--- End quote ---
Would be great to get an own package for it. But it's not something that is a must-have.
Offtopic
Which reminds me of a totally different thing: How can I request an update for a specific package where a new version is available but it's not yet in debian? I'm talking about libcunit - there is a new version available that fixes a lot of warnings due to added const keywords. It would be great to have this updated. But I don't know much about this process. Can you guide me a little?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version