well you should simply find the Spring Engine in the Software center of Ubuntu (Gnome) its now there from beginning same like Kernel Panic but S44 isn’t still there you need the sdz file from the homepage, then. So the Spring Engine (source) comes with Karmic (for sure you need to download Spring over the Software Center). However i hope you can upgrade the threat so that i can edit my Wiki Article.
Sure, spring and SL are in karmic universe, but packages are already outdated.
I’ve copied current packages from spring dev ppa now, so s44 karmic repo should be good to go. Anybody know how the fancy knew ppa handling works on karmic yet? Would be nice if someone posts it so I can update the first post with instructions. I won’t be having a karmic box for some time.
I’m trying Karmic final, and installed spring from karmic sources, and works,
New handling on ppa is very simple on karmic.
I use Kubuntu, no gnome, but it’s the same with Ubuntu Software Center than kpackagekit.
Open sources and add ppa:s44/karmic, reload, and search spring.
Testing new packages now,
Koshi, I was wondering about whether we could shoe-horn S44 into the full/default Ubuntu/Debian repositories upon the release of MG. I assume this is unnecessarily difficult because we are CC-NC and thus “not free” for certain baloney development definitions of free. Their repositories do include non-free content, however… is there a way to say, include S:44 as a non-free game in the default Universe/Multiverse for Games & Entertainment, then have it grab Spring as dependency from the "free"verse and another pair of map packages - the NC maps and the PD maps?
I’m reasonably certain this can’t be done, but I wanted to discuss the possibility. It is quite annoying to see Glest in every damn game list when it is essentially a Warcraft III clone.
For buntu the Multiverse is definitely possible, iirc tremolous has some nc assets too. This will need the help of a Motu probably. I should also note that the next buntu (lucid lynx, 10.04) is already in package freeze afaik. So next possible would be 10.10 which should enter package freeze mid august.
Edit: packages.debian.org/search?keywo … ection=all
wasn’t thinking logical
What about releasing Spring 1944 with CC-BY-SA, so that it could be packaged in main repository of Debian/Ubuntu? Would it change something for the developers?
Note that Tremolous is CC-BY-SA but it’s in non-free/multiverse because it has CC-BY-SA 2.5. CC-BY-SA 3.0 is Debian compatible (next version of Tremolous will be indeed CC-BY-SA 3.0, see http://tremulous.net/forum/index.php?topic=8448.0).
Having it packaged in distribution repository is nice because it get automatically updated on new distribution versions, recompiled when there are updated library and most importantly it is a lot more visible and easy to install to end users: just open your package manager go to game section, find and install it with a few clicks.
We will never drop NC in favour of SA. It is non-debatable.
Key developers, particularly those who have contributed the majority of the artwork, have refused to release their work without the Non-Commercial stipulation.
In fact, there is no valid reason why our current licensing is considered incompatible, but that is a discussion we’ve long since put behind us. The only articulate arguments against NC put forth are those of Erik Moller (freedomdefined.org/Licenses/NC), and they utterly marginalize, rather than address, the ideological reasons for non-commercial licensing. I personally don’t care that much, I’d prefer BY-SA and the accessible work of mine which is not BY-SA is usually PD. I say the accessible work because I also attempt to produce for commercial consumption elsewhere.
You may debate this, but it is not within the power of any individual developer to change the license and the situation is unlikely to change. We would probably need agreement among the active developers (Nemo, FLOZi, Zvero, Yuri, Myself) as well as element relicensing by various contributors.
The short version of our philosophy there is this: we don’t want anyone selling our assets in any form, because they represent a ginormous number of man-hours of work and it just feels wrong for others to take that and be able to then include them in a commercial package.
However! we really do want people to be able to use our assets for their own hobby projects, and the way to maximally enable that usage is to not handcuff the users of our content to a viral license clause like SA. If someone wants to use our stuff but not share the modifications/package, we’re okay with that - as long as they aren’t selling said package/modifications.
preview of the upcoming new package:
(spring1944-1.4x will eventually become 1.5 once i’m satisfied with the package)
- update the -maps package to mirror those in windows installer
- include a s44 icon for the starter
- testing of said starter
- build for maverick & karmic
What about dual licensing the game with CC-BY-NC + CC-BY-SA?
- CC-BY-SA will make the game DFSG compatible and easily packageable by Linux distributions
- with CC-BY-SA the game could be included with DVD of game magazines increasing its popularity
- commercial games could then use the game content using CC-BY-SA but any modification will have to be made available under the same license. Anyway it’s unlikely any commercial game will want to use any CC-BY-SA content (I never heard it happening).
- hobbyist could still use the game with CC-BY-NC without sharing their improvements
Usually CC-BY-SA games are better perceived among the linux/free communities, just look at the increasingly popularity of the 0 A.D. game when it got licensed under GPL + CC-BY-SA, it also got new developers. Just my 2c and sorry for the nuisance
Should I be waiting for MG 1.5.1 to push new stuff?
Could we have the license stuff split and this request then be removed?
Dual licensing means that you could keep both licenses, no need to drop NC, just add SA, BTW.
great can’t wait to play it under maverick
@koshi: thanks for the packages! Some issues below:
The spring-engine source package has been deprecated by the spring package in maverick and will be soon dropped (see bug #612905). It’s no longer needed on maverick (already has 0.82.5.1) and you should rebase the lucid and karmic packages on it.
Then you should change spring1944 packages to Depend on spring rather than spring-engine (see also maverick packaging of Kernel Panic).
You could also rebase springlobby to what’s currently in maverick.
The spring1944 maps packages are empty.
Also rather than versioning the packages 1.4.x you should use something like: 1.5.0~0koshi0lucid, and upgrade the second 0 on new versions, like 1.5.0~0koshi1lucid .
Re the maverick stuff: Yokozar (Scott Ritchie) told me last Wednesday, I just haven’t adapted yet.
The empty maps package was my failed attempt at using only one source package upload for multiple series to not break ppa size limits. Then I realized that copying the same package to a different series seemingly does not count towards that limit.
Yeah I guess so. It saw that would remove that launcher
script previously necessary.
Could you elaborate on the reasoning for that? I find myself continuously confused by seemingly arbitrary and sometimes conflicting versioning schemes.
The debian main version should match the program version (1.5.0) or else you’ll get warnings when building the package (it’s also consistent with the program version for end users, expecting the rigth version).
The ~ means “less” ,e.g. 1.5.0~0 < 1.5.0-0. The latter is used in official debian/ubuntu archives, so these packages (being the official ones) should be preferred when there are packages with same major version.
The numbers 0,1 should be updated when you do a new package to get the new version. The lucid/maverick should also be added so that when you upgrade from lucid to maverick you also upgrade the package and doesn’t keep the old version compiled for lucid.
(I wonder how you were able to push packages with same version on different release, 1.4.10 is on both lucid and maverick, since usually this give me an error…)
Thanks a bunch. That makes more sense than what I’ve read up till now.
I wasn’t able and yes dput refuses to upload changes for same version (albeit different series) for me as well. I used the ‘copy packages’ feature on the web interface. That allows copying to a different series (different ppa too ofc) without rebuilding.
Updated first post with new instructions for new ppa.
Stuff is now split in 3 packages:
- spring1944-data: the acutal game .sdz
- spring1944: a kind of meta package that depends on -maps and -data, spring and springlobby and also ships the SpringLobby customizations and launchers