Spec URL: http://www.daughtersoftiresias.org/progs/el/eternallands.spec Spec URL: http://www.daughtersoftiresias.org/progs/el/eternallands-music.spec SRPM URL: http://www.daughtersoftiresias.org/progs/el/eternallands-1.3.2.0-1.src.rpm SRPM URL: http://www.daughtersoftiresias.org/progs/el/eternallands-music-1.3.2.0-1.src.rpm Description: "Eternal Lands is a free MMORPG (massively multiplayer online role playing game) currently under development. The game is now in beta stage, and is fully playable. We are constantly adding more things to do, more items to make, monsters to fight, and improving the systems." Build notes: Eternal Lands has a somewhat nonstandard build process, in that there are few fixed "releases", and some of the files have no tarball that contains them. Rather, there is a "base", and changes (models, textures, etc) are pushed through updates or special update packages that don't contain the whole base. As such, I had to set up my own tar-building process that takes a recent binary dir and a recent source tree and combines them into a tarball that can be distributed. You'll also note that the permissions in directories that can have content pushed to them are less restrictive. No binaries or libraries are ever pushed. As the music is so large, as is common with games, eternallands is split up into binary and music packages. The music package is optional.
Maybe I'll make a review tommorow (but I'm not sure), but I see a few faults here, in spec file. 1) Why do you use "-n eternallands-%{version}" parameter to %setup macro? By default, rpm tries to change directory to %{name}-%{version}. 2) I think that inclusion wrapper as an another source would be better than creating it in spec file (only imho). 3) data files shouldn't go into %{_datadir}/games/%{name}, but %{_datadir}/%{name}. Read http://fedoraproject.org/wiki/Extras/SIGs/Games for further information. 4) post scripts look wrongly (read http://fedoraproject.org/wiki/ PackagingDrafts/ScriptletSnippets) And the last thing: creation of your own tarball may be a problem to a reviewer. I think you should include all tarballs as sources and make any required modifictions in %prep section and/or patches.
Uh... Well it looks like this package cannot be approved in Extras. I have read the license and it doesn't look like a license might be approved in Extras.
Now, I am sure. Sorry, but this package cannot be approved. Its license is bad. I wanted to make me sure on irc channel: <tibbs> Clause 4 is definitely bad. <tibbs> Freedom to modify is essential so that you can do things like fix security issues. <tibbs> Clause 3 is probably bad as well. So I have to close the review.
Now this is frustrating. Because, according to this page: http://fedoraproject.org/wiki/Packaging/Guidelines "The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from open source software. In accordance with that, all packages included in Fedora must be covered under an open source license. We clarify an open source license in three ways: * OSI-approved license. You can find the list of OSI approved licenses here: http://www.opensource.org/licenses/ " So, I went to http://www.opensource.org/licenses/, and I see this: http://www.opensource.org/licenses/qtpl.php What is up with this? I just spent a couple hours packaging this because it looked like this license was acceptable. Now you tell me that it isn't? Looking into it more, it seems you're talking about the restrictions to the license as opposed to the license itself. For number 4, this RPM is a piece of client software. Just because a server choses not to allow modified clients to connect doesn't mean that you can't modify the client. You can modify this client to your heart's content -- you'll just need your own server if you want to connect legally. Any security changes that don't go straight into the EL tree or have EL permission should, responsibly, change the address that the server points to, just to make sure that users realize that it's a modified client. If this is unacceptable to Fedora, then Fedora will *never* be able to have a MMORPG in with it, because modified clients are the bane of MMORPGs, as they allow botting. EL is actually nicer than most -- you can use modified clients, so long as you register them and they're not obscenely cheating, and they're very good about accepting patches. As for #3, the first part is implicit in all licensing agreements. You're never allowed to use other peoples' trademarks without their approval, whether their code is Open Source or not. Is the second part a problem? Right now, I'm looking at the LGPL, and it's little different: "You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change." Oy. Is there a way to get preapproval or anything so that this doesn't happen again in the future? Anyways, as to the other stuff: <I>1) Why do you use "-n eternallands-%{version}" parameter to %setup macro? By default, rpm tries to change directory to %{name}-%{version}.</I> I based this on the nethack-vultures specfile, which Ville built the framework of. <I>2) I think that inclusion wrapper as an another source would be better than creating it in spec file (only imho).</I> If you'll notice, part of the wrapper depends on the installation directory. Since it's so short, I figured this was cleaner than having a separate source that I'd have to sed to customize. <I>3) data files shouldn't go into %{_datadir}/games/%{name}, but %{_datadir}/%{name}. Read http://fedoraproject.org/wiki/Extras/SIGs/Games for further information.</I> Can do. Once again, however, the nethack-vultures spec installed in there. So it must be wrong as well. <I>4) post scripts look wrongly (read http://fedoraproject.org/wiki/ PackagingDrafts/ScriptletSnippets)</I> This is also straight from nethack-vultures, and is code I was given from Ville. What is the issue with what you see, out of curiosity -- is it the lack of an "if"? <I>And the last thing: creation of your own tarball may be a problem to a reviewer. I think you should include all tarballs as sources and make any required modifictions in %prep section and/or patches.</I> But there are no tarballs except the initial and one update, which has been heavily modified over time by additional files (they're zips, not tarballs, but that's not important). There are no up-to-date original tarballs, so there is no option but to create a new one each time.
In short, what I'm saying is: tell me what needs to happen to make this approvable, and I'll work on getting those things done.
I'm sure there is a lot of interest in this game. Please be very certain the license is not acceptable before closing the bug. If this is the case, we can always package it for Livna or Dribble. But most of us would prefer it in Extras if possible. The license looks okay to be, but I am not a lawyer. Perhaps we can bring it up on the fedora extras mailing list if there is a question.
Karen: You might want to list this bug on the Games SIG page: http://fedoraproject.org/wiki/Extras/SIGs/Games
4. If you want to [re]distribute this game, you are NOT allowed to modify anything. You can, however, distribute some txt/doc/etc file, with information about you, etc. Okay, this definately is no good for Fedora. Please submit package to Livna or Dribble.
Chris: Where are you seeing that? I just searched through eternal_lands_license.txt, and that text is not there. The game is QTPLed, with a few restrictions. QTPL is, according to Fedora Extras's docs, and acceptable license. So the only issue should be the restrictions. As per the security modifications issue: From entropy, one of the lead EL developers: "If they discover a security issue, they should submit a patch and a description to us, and we will include it right away in the CVS. Alternatively, they can just ask for our approval to distribute their own changes in the Fedora package, and if it's only a security issue that doesn't create any cheating, we will grant them the permission."
Hmm, I see it: the "plain language" license differs strongly with the real license. I'll point out the contradiction to the developers.
I've posted the contradiction to them. This should be fixed soon. Christopher: https://bugzilla.redhat.com/bugzilla//process_bug.cgi says that it's an "immutable page". I can't edit it to add this link there.
Karen: That's good news about the license. I think the license that actually comes with the software would override the one on the web site. We should definately confirm with upstream developers, but this is good news! I added this bug to the Games SIG page for you.
Bad news: It looks like the developers went with the "Quake" model here: that is, all of the code is under a free, open license, but all media (artwork, sounds, models, levels, etc) are not. Now, if it were only "some" of the media that wasn't open, we could take the whole xmms/mp3 route and ship a partially crippled product. However, since it all isn't open, all we'd be left with is something which doesn't do anything on it's own. It'd be a valid code base for others to tweak, but as it stands, it wouldn't do anything. I withdraw the package, unless anyone thinks that there's a workable solution here. I'll try taking it over to one of the other repos -- perhaps ATrpms. I'll have to look into how you become a developer there. ;)
Well, I suppose that I closed it prematurely. Lets just make sure: if the code is OSS, but the artwork isn't allowed to be modified, it's not allowed, right? Or is it?
Er, isn't allowed to be included in other projects. They'd allow
You could possibly seperate the artwork from the software, but if the software is useless without the artwork this doesn't make much sense. ATrpms is not compatible with Fedora (despite what they claim) and using this repo will only mess up your system. You should use either Livna http://rpm.livna.org/ or Dribble http://dribble.org.uk for software that cannot go into Extras.
I've never actually heard of Dribble, and I use a fair number of repos. I could go with Livna. I use ATrpms on my home system and have never had any problems. What problems have you had?
ATrpms overrides official Fedora RPMs and basically you end up destroying your system. I have seen countless people come in #fedora with their messed up systems and every time its because they have ATrpms packages installed. If your system hasnt messed up yet, then you have been very lucky. You should immediately remove all ATrpms you have installed on your system and replace them with offical Fedora rpms from one of the repos mentioned above. I do not use ATrpms so I have never had any problems myself. If there is an ATrpms package that is not available on any of the "official" repos listed above, let us know.
It's people like Chistopher Stone and their aggressive FUD that creates the chasms between repos.
It's not just me Axel, it is the _entire_ Fedora community. You should not EVER replace, upgrade or obsolete any packages found in Core or Extras. Period. If you no longer do this, then correct me, and I will apologize.
Placing yourself as the frontman of the community doesn't make your FUD more true.
Hey, if you dont believe me, why don't you subscribe to the fedora-extras (or fedora-maintainers or fedora-packaging) mailing list and ask the community yourself.
Thanks for the advice, I'm on all of these lists and in very good contact with all parts of the community.
Okay, for those who did not follow the discussion on the mailing list, here is the summary: - ATrpms contains packages which update or replace packages in core - These replacements make debugging problems more difficult - Telling a user to remove those packages is a valid mechanism for simplifying a problem. - People who use ATrpms no longer have a "Fedora" system. They have a "Fedora/ATrpms hybrid" system. - Comments made by myself were not "unacceptable". Let me reiterate what was stated in comment #20: A repository should never replace, upgrade or obsolete any packages found in Core or Extras. Period.
Now, how can you be summarizing a still ongoing discussion? And the way you censor off all the unpleasant parts of it, that's really amazing! The truth is that I have reported Christopher Stone's misbehaviour (FUD) on fedora-maintainers. Furthermore Christopher suddenly "remembered" that contrary to comments made here he has used ATrpms before, even several times and even recently. The current status is that after two board members having called Chistopher back to reason (his bugzilla comments were labeled as "too much invective" and having no place here) his facts suddenly started to melt down - currently they have become unspecific "potential breakage". But don't trust either side of summarizing: https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00097.html
Right, you reported what could be construed as inappropriate comments made by me. And I will admit that I was not tactful, and some of the things I said could have been stated better. However, this is not what I asked you to ask the community. I stated that a repository should never override base packages and you called this "FUD" and yet you never asked the community about this. Instead you concentrated on a *much* more irrelevent issue by focusing on my comments. Let me state once again. A repository which overrides base packages essentially forks Fedora and creates its own distribution. This is *far* more damaging to the community than any comments made by a single individual. So, let me say that I apologize for my comments and I am sorry they made you so upset. But there is a greater issue here, and that is ATrpms is overriding Fedora core packages. I will give a sincere apology to you in front of the entire community if you remove these packages that are already in FC/FE, but judging from your actions so far, I don't think this will happen.
You're still mispresenting the discussion. a) I called FUD your comments on ATrpms breaking every system, not what you're trying to put in my mouth b) Fudding around like you do is not irrelevant, in fact it either splits the community or creates short-minded thought-to-be solutions like partial/selective repository enablement which generates the true bugs. c) You judge too much d) This discussion is off-topic here, I escalated this to fedora-maintainers where it belongs. Please keep this package submission FUD and rage free and let it return back to its own topic. See you on fedora-maintainers.
Well, since nobody has posted that they think there's a way to include this package, and since it's way off topic now, and since it's now in ATrpms, I'm going to go ahead and re-close this thread.
Karen: Since ATrpms forks Fedora and makes life difficult for everyone in the community I will use your RPMs and add them to Dribble since I already have an account there. AT: Since you will never make any effort to stop forking the distribution and you are far more concerned about people telling other people to not use your damaging repository I will continue to encourage people to not use your repo.