Spec URL: http://www.hajnet.cz/soubory/ufoai.spec SRPM URL: http://www.hajnet.cz/soubory/ufoai-2.1.1-1.fc8.src.rpm Description: UFO: ALIEN INVASION is a strategy game featuring tactical combat against hostile alien forces which are about to infiltrate earth at this very moment. You are in command of a small special unit which has been founded to face the alien strike force. To be successful on the long run, you will also have to have a research team study the aliens and their technologies in order to learn as much as possible about their technology, their goals and the aliens themselves. note: the srpm is 293 MiB big ... if the server is too slow, please download the source files from Sourceforge and rpmbuild the srpm yourself; for that purpose you need also the icon file which is taken from the installer - you'll find it here http://www.hajnet.cz/soubory/ufoai.xpm there is a problem with the game.so library which is by default placed in the game datadir, but rpmlint complains about arch-dependent-file in /usr/share ... so that I've modified the sources to force loading the library from the library dir - putting there absolute path is nearly as bad, but splitting data and game library paths would require heavy hacking of the sources :-( another problem is that the game needs some options set to run - this is not a problem using the .desktop file, but there should be also some solution for the console ... maybe adding some wrapper script? are there any recommendations?
Thanks for packaging this, I'll take a look at this as time permits, may take a while though as I'm really awefully busy with other stuff ATM. Other reviewers feel free to pick this up in the mean time, but notice that Karel needs a sponsor.
oops, it looks like I have missed the game packaging guidelines :-( http://fedoraproject.org/wiki/SIGs/Games#head-367e7208aacfec8f8aff1b34c1795e43c0967ecd so I have to split data to a separate package and use OpenGL Wrapper ... anything else before I make the second revision?
If the music is large and optional, you could consider putting it in a package of its own too. Other then that, since you are using opengl-games-wrapper, you will need a wrapper symlink anyways, so you might want to replace this with a wrapper bash script, so the launching with the correct options from the cmdline is possible too. See vegastrike for an example of how to integrate opengl-games-wrapper into an other bash script.
(In reply to comment #2) > so I have to split data to a separate package er, is there any way to have one spec file and to have the data subpackage noarch? - from a quick googling, it looks like a "known bug" that it can't be mixed ...? is it a big problem not having the data package noarch so that I do not need to split the specs and sources? > and use OpenGL Wrapper ... thinking about it ... the game is using SDL and runs without hardware acceleration, so "If a game requires 3D" is not true - the other thing is that without 3D driver, it "runs" like a snail (but still you can play it)
(In reply to comment #3) > If the music is large and optional, you could consider putting it in a package > of its own too. so, actually you mean two separate data packages? data are 256 MiB, the additional music is 33 MiB (and yes, it is not needed, but ... I would miss it ;-)), is that worth it? > Other then that, since you are using opengl-games-wrapper, you will need a > wrapper symlink anyways, so you might want to replace this with a wrapper bash > script, so the launching with the correct options from the cmdline is possible > too. See vegastrike for an example of how to integrate opengl-games-wrapper into > an other bash script. yes, I'll do that this way - if I really should use the OpenGL Wrapper, see above ...?
(In reply to comment #4) > (In reply to comment #2) > > so I have to split data to a separate package > > er, is there any way to have one spec file and to have the data subpackage > noarch? - from a quick googling, it looks like a "known bug" that it can't be > mixed ...? > No, but if upstream distributes separate tarbals (and they do) you must make seperate srpms. Then when someone fixes an engine bug, all users will thank you for not having to redownload the data files again, which is what would happen on a yum update if all were in the same spec, as you cannot rebuild only certain sub-packages, when rebuilding all get rebuild, and the all get a higher EVR, so even though the data isn't changed a yum update will still download it. > is it a big problem not having the data package noarch so that I do not need > to split the specs and sources? > Yes, not the noarch part, but ... see above. > > and use OpenGL Wrapper ... > > thinking about it ... the game is using SDL and runs without hardware > acceleration, so "If a game requires 3D" is not true - the other thing is that > without 3D driver, it "runs" like a snail (but still you can play it) If its really playable without accel then thats ok. The wrapper is there for cases where software rendering goes so slow the mouse becomes very jumpy and even navigating to the quit entry of the menu becomes hard. (In reply to comment #5) > (In reply to comment #3) > > If the music is large and optional, you could consider putting it in a > package > > of its own too. > > so, actually you mean two separate data packages? > Yes 2 seperate packages not sub-packages but seperate packages, with their own .spec and src.rpm, see above. > data are 256 MiB, the additional music is 33 MiB (and yes, it is not needed, > but ... I would miss it ;-)), is that worth it? > Yes, for some it may very well be worth it, not everyone has high speed internet links.
(In reply to comment #6) > No, but if upstream distributes separate tarbals (and they do) you must make > seperate srpms. well, this should be written in the guidelines ... > Then when someone fixes an engine bug, all users will thank you > for not having to redownload the data files again, which is what would > happen on a yum update if all were in the same spec, as you cannot rebuild > only certain sub-packages, when rebuilding all get rebuild, and the all get > a higher EVR, so even though the data isn't changed a yum update will still > download it. somehow I thought that I can specify different release for the subpackages, but thinking about it, its nonsense ... thanks for the explanation > If its really playable without accel then thats ok. The wrapper is there for > cases where software rendering goes so slow the mouse becomes very jumpy and > even navigating to the quit entry of the menu becomes hard. well, the latter is true on most machines that I tried, so no doubt the wrapper should be added so here we go: http://www.hajnet.cz/soubory/ufoai.spec http://www.hajnet.cz/soubory/ufoai-2.1.1-2.fc8.src.rpm http://www.hajnet.cz/soubory/ufoai-data.spec http://www.hajnet.cz/soubory/ufoai-data-2.1.1-1.fc8.src.rpm http://www.hajnet.cz/soubory/ufoai-music.spec http://www.hajnet.cz/soubory/ufoai-music-2.1.1-1.fc8.src.rpm a few outstanding issues: - I've noticed that the license file for music states that the author does not wish it to be used in other projects, but no separate licensing is mentioned on the project page or anywhere else so that the same as the whole project, GPLv2+, should be used, imho ... or should I consult fedora-legal-list? (I'm not a member) - I do not understand why "dash-EOF" syntax does not work as expected within the wrapper generation ... not a big deal, though :-) - rpmlint complains about missing %build for the data and music packages ... is that mandatory to have this section even if empty? - afaik, rpm does not support optional dependencies, how to suggest installation of ufoai-music together with ufoai without depending on it hard?
> - I've noticed that the license file for music states that the author does not > wish it to be used in other projects, but no separate licensing is mentioned > on the project page or anywhere else so that the same as the whole project, > GPLv2+, should be used, imho ... or should I consult > fedora-legal-list? (I'm not a member) You have to use the license of the code itself -- look into source. Consulting with legal team is a good idea, setting FE-legal. > - I do not understand why "dash-EOF" syntax does not work as expected within > the wrapper generation ... not a big deal, though :-) > > - rpmlint complains about missing %build for the data and music packages ... > is that mandatory to have this section even if empty? Yes, leaving it empty does not harm. > - afaik, rpm does not support optional dependencies, how to suggest > installation of ufoai-music together with ufoai without depending on it hard? I don't know of any way to do that. Maybe anyone else?
That music use restriction would conflict with the GPL, so I suspect that this is not the correct license for the music files. Ask upstream, see if they can clarify the license on the music files.
(In reply to comment #9) > Ask upstream, see if they can clarify the license on the music files. so I have tried - hope I got the problem straight ... here's the reply: Hello, I authorize you to package UFO: Alien Invasion music soundtrack, as long as you include my name in the package and my web address: Manuel Marino http://manuelmarino.com thank you! -----Messaggio originale----- Da: Karel Volný [kvolny] Inviato: giovedì 13 dicembre 2007 12.09 A: manuelmarino Oggetto: UFO:AI music Hello, I would like to package UFO: Alien Invasion for the Fedora Linux distribution. However, I have come across a little legal problem concerning your music for the game. The file license.txt distributed together with your music tracks states: Music Licence Agreement ======================= Music has been composed and produced by Vanethian (www.manuelmarino.com). All rights reserved. Do not use the tracks in another project Unfortunately, this is not clear enough for us - to be exact, it does not explicitly state that we may redistribute the files. So, I would like to kindly ask you to make the things clear. Please take a look at http://fedoraproject.org/wiki/Licensing#head-1a4233369331c74272de8e48132a0b1 6b63e61d8 - it would be very helpful if you could simply use anything from the list of the "Good Licenses" (personally, I would suggest CC-BY-ND, if I understand your intentions). The issue is discussed at https://bugzilla.redhat.com/show_bug.cgi?id=412001 You may reply directly there, possibly attaching new license file which we could include within the package, or I will quote there relevant parts of your answer if you prefer to talk to me personally. It would be a pity if we would have to leave out such a piece of work just because of some legal uncertainties ... Thank you in advance for your answer - and many thanks for helping the UFO:AI project! Regards, K.V.
I'm afraid that that still is a bit unclear, for example what about redistribution by people receiving the music through Fedora? Spot, I've added you to the CC to take a look at this licensing issue again, what do you think about the "license" given by upstream in comment #10? Also since this now are 3 separate packages this also should be 3 separate review requests (for tracking by various automatic status script to give one reason), Karel can you please file 2 seperate review requests for the data and musc packages? Thanks!
(In reply to comment #11) > [...] > Also since this now are 3 separate packages this also should be 3 separate > review requests (for tracking by various automatic status script to give one > reason), Karel can you please file 2 seperate review requests for the data and > musc packages? Why not make sub-packages of these?
(In reply to comment #12) > (In reply to comment #11) > > [...] > > Also since this now are 3 separate packages this also should be 3 separate > > review requests (for tracking by various automatic status script to give one > > reason), Karel can you please file 2 seperate review requests for the data and > > musc packages? > > Why not make sub-packages of these? > Already discussed, see comment 6.
(In reply to comment #11) > I'm afraid that that still is a bit unclear, for example what about > redistribution by people receiving the music through Fedora? > > Spot, I've added you to the CC to take a look at this licensing issue again, > what do you think about the "license" given by upstream in comment #10? Yeah, it is still unclear. Ask upstream if the music is freely redistributable.
Perhaps better ask if its freely redistributable together with ufoai, considering what was in the orginal README. AFAIK that (freely redistributable together with game foo) is acceptable for Fedora too (already have such content AFAIK).
(In reply to comment #11) > Also since this now are 3 separate packages this also should be 3 separate > review requests (for tracking by various automatic status script to give one > reason), Karel can you please file 2 seperate review requests for the data and > musc packages? done ... hope I got it all right
(In reply to comment #14) > Yeah, it is still unclear. Ask upstream if the music is freely redistributable. I tried ... please, can somebody with better social skills than me take care of getting the right answer if that e-mail reply is not good enough? (In reply to comment #15) > Perhaps better ask if its freely redistributable together with ufoai, > considering what was in the orginal README. AFAIK that (freely redistributable > together with game foo) is acceptable for Fedora too (already have such content > AFAIK). I tried to reflect this within the new revision of ufoai-music, see bug 425957, but I am really not sure if it is acceptable this way
Marel, Sorry for taking over your review, but I'm in the process of sponsoring Karel. Full review done, all in all it looks good, some minor issues and your missing some buildrequires to enable openal audiooutput and fullscreen when using the X11 display driver: Must Fix -------- * Add BuildRequires: freealut-devel libXxf86vm-devel libXxf86dga-devel * "Encoding=UTF-8" in the .desktop file is deprecated please remove it * rpmlint: W: file-not-utf8 /usr/share/doc/ufoai-2.1.1/CONTRIBUTORS p.s. Removing FE_LEGAL (and adding it to the -music subpackage)
ping?
(In reply to comment #19) > ping? pong, I was on vacation (In reply to comment #18) > Must Fix > -------- > * Add BuildRequires: freealut-devel libXxf86vm-devel libXxf86dga-devel > * "Encoding=UTF-8" in the .desktop file is deprecated please remove it > * rpmlint: W: file-not-utf8 /usr/share/doc/ufoai-2.1.1/CONTRIBUTORS all done I've also added a fix for rpmlint complaints about: ufoai.x86_64: W: file-not-in-%lang /usr/share/ufoai/base/i18n/cs/LC_MESSAGES/ufoai.mo ... Spec URL: http://www.hajnet.cz/soubory/ufoai/ufoai.spec.2.1.1-3 SRPM URL: http://www.hajnet.cz/soubory/ufoai/ufoai-2.1.1-3.fc8.src.rpm
As discussed in bug 425956, the needed data unfortunately is not properly licensed for Fedora atm. Thus I'm also closing this review as the guidelines do not allow for a "useless" package to be packaged, basicly the rule is that if a package needs some content to function and is completely not functional without that content it cannot be part of Fedora.
as for the license issues, we'll have to wait at least until the number of "UNKNOWN" drops to zero: http://phidev.org/~dino/ufo/html/index.html ... a long run case I guess :-(
latest versions - SPECS: http://www.hajnet.cz/soubory/ufoai/ufoai.spec.2.2 http://www.hajnet.cz/soubory/ufoai/ufoai-data.spec.2.2 http://www.hajnet.cz/soubory/ufoai/ufoai-doc.spec.2.2 http://www.hajnet.cz/soubory/ufoai/ufoai-music.spec.2.1.1-2 SRPMS: http://www.hajnet.cz/soubory/ufoai/ufoai-2.2-1.fc8.src.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-data-2.2-1.fc8.src.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-doc-2.2-1.fc8.src.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-music-2.1.1-2.fc8.src.rpm binaries: http://www.hajnet.cz/soubory/ufoai/ufoai-2.2-1.fc8.x86_64.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-data-2.2-1.fc8.noarch.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-debuginfo-2.2-1.fc8.x86_64.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-doc-2.2-1.fc8.noarch.rpm http://www.hajnet.cz/soubory/ufoai/ufoai-music-2.1.1-2.fc8.noarch.rpm 1096 UNKNOWN licenses to solve ATM :-(
in Livna, see http://bugzilla.livna.org/show_bug.cgi?id=1836