Bug 412001 - Review Request: ufoai - UFO: Alien Invasion strategy game
Review Request: ufoai - UFO: Alien Invasion strategy game
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
Depends On: 425956
Blocks: FE-DEADREVIEW 425957
  Show dependency treegraph
 
Reported: 2007-12-05 09:11 EST by Karel Volný
Modified: 2008-02-19 07:32 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-07 14:21:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2007-12-05 09:11:53 EST
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?
Comment 1 Hans de Goede 2007-12-05 09:52:01 EST
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.
Comment 2 Karel Volný 2007-12-05 12:36:22 EST
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?
Comment 3 Hans de Goede 2007-12-05 14:06:01 EST
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.
Comment 4 Karel Volný 2007-12-05 14:31:00 EST
(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)
Comment 5 Karel Volný 2007-12-05 14:35:45 EST
(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 ...?
Comment 6 Hans de Goede 2007-12-05 14:43:28 EST
(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.
Comment 7 Karel Volný 2007-12-06 09:17:22 EST
(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@redhat.com? (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?
Comment 8 Marek Mahut 2007-12-12 06:48:21 EST
> - 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@redhat.com? (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?
Comment 9 Tom "spot" Callaway 2007-12-12 13:41:56 EST
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.
Comment 10 Karel Volný 2007-12-13 07:22:46 EST
(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ý [mailto:kvolny@redhat.com] 
Inviato: giovedì 13 dicembre 2007 12.09
A: manuelmarino@manuelmarino.com
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.
Comment 11 Hans de Goede 2007-12-14 14:38:34 EST
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!
Comment 12 Marek Mahut 2007-12-14 14:48:40 EST
(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?
Comment 13 Hans de Goede 2007-12-14 14:51:47 EST
(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.


Comment 14 Tom "spot" Callaway 2007-12-14 15:03:34 EST
(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.
Comment 15 Hans de Goede 2007-12-15 02:35:19 EST
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).
Comment 16 Karel Volný 2007-12-17 08:05:34 EST
(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
Comment 17 Karel Volný 2007-12-17 08:14:49 EST
(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
Comment 18 Hans de Goede 2007-12-21 07:44:44 EST
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)
Comment 19 Hans de Goede 2008-01-04 04:25:32 EST
ping?
Comment 20 Karel Volný 2008-01-07 12:11:21 EST
(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
Comment 21 Hans de Goede 2008-01-07 14:21:14 EST
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.
Comment 22 Karel Volný 2008-01-15 08:43:36 EST
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 :-(
Comment 24 Karel Volný 2008-02-19 07:32:08 EST
in Livna, see http://bugzilla.livna.org/show_bug.cgi?id=1836

Note You need to log in before you can comment on or make changes to this bug.