Re: cube2 and cube2-data ready for tests
Hi Markus,
On Mon, Mar 3, 2014 at 12:04 PM, Markus Koschany <apo@gambaru.de> wrote:
> On 01.03.2014 15:05, Paul Wise wrote:
> [...]
>> Well it depends on what you intend to do. If you are just going to
>> keep it as a copy of the wake6 upstream then yes wake6 is an
>> appropriate name. If you are going to fork wake6 into a new upstream
>> then yeah, give it a new name.
>
> I'm definitely in favor to "fork" wake6 into cube2-data to allow others
> to build upon this package. I guess the new homepage will be
>
> https://wiki.debian.org/Games/Cube2
I'd suggest a github/gitorious repo as the homepage if you want to
make it easier to collaborate with others (as opposed to the scope
being limited to Debian only).
> I think I am almost done with the transition of the sauerbraten game to
> the cube2 and sauerbraten source packages.
>
> You can find my latest work at:
>
> http://anonscm.debian.org/gitweb/?p=pkg-games/cube2.git
>
> and
>
> http://anonscm.debian.org/gitweb/?p=pkg-games/sauerbraten.git
>
> @Vincent
>
> Are you happy with Git?
I'm happy with git...
...but I'm not so happy that you've gone and wiped all the history
from the sauerbraten git repo and started from scratch. And I just
realized I don't have a clone of the packaging on my laptop, so if
you've gone ahead and deleted the repo on moszumanska without backing
it up... *sigh*
Does anyone know if there's some way to retrieve backups of stuff
hosted on Alioth, by the way?
> I have verified that the transition actually succeeds and used Conflicts
> instead of Breaks to ensure that it really works, that the old
> sauerbraten packages get removed first. I'm only unsure if we should
> keep the sauerbraten-dbg and sauerbraten-server binary packages in their
> current form. Both are dependency packages and arch:all in non-free
> although they contain nothing non-free. However I think they are useful
> to pull in the real cube2-dbg and cube2-server packages. The (=
> ${binary:Version}) makes probably not much sense with dependency packages?
>
> Any ideas how they could be improved?
You mention earlier that you've repacked the tarball to remove the
bundled enet library:
* Repack source package and unbundle the embedded enet library. Build
against the shared system library instead.
Upstream explicitly says not to do that [1], i.e.:
"With respect to libraries, make sure that you do not link Sauerbraten
against any other ENet package
than the one that comes included with the Sauerbraten, as it may be
different from the official ENet
releases and might fail to compile or communicate properly."
I don't like embedded libraries any more than any other maintainer,
but if it causes things to break (read: supertuxkart + system irrlicht
= subtle graphical/rendering glitches that I didn't notice until a few
months later (= a whole slew of bug reports on launchpad from angry
ubuntu users)), I'd much rather keep using the embedded lib. If not
using sauerbraten's bundled version of enet causes e.g. problems with
multiplayer, definitely revert back to using the bundled library.
I haven't yet had time to review all your packaging changes in detail, sorry.
Regards,
Vincent
[1] http://sourceforge.net/p/sauerbraten/code/HEAD/tree/bin_unix/readme.txt
Reply to: