Bug 147061

Updated package at http://fedora.laiskiainen.org/SRPMS.extras/ BUT: as
far as I can tell 0.8.9 is a development release - as such it perhaps
shouldn't be going to Extras (except perhaps the development-branch)

As I've supported a network neighbour with unofficial updates for the
fedora.us package several times, he just said:

"Wesnoth 0.8.10 is out. :p  There is great progress in the development
releases. But they are not quite stable and you cannot transfer saved
games between them without problems. Which would happen in a big
upgrade anyway. Haha! Also, the main game server is for the last
stable release. And the development releases use a different server."

However, I found this in the announcement of 0.8.10:
http://www.wesnoth.org/forum/viewtopic.php?t=4513

 * "The last release had some critical bugs that have forced us to go
back to the release often philosophy. "

 * "server.wesnoth.org will soon be running 0.8.10 and can be used for
multiplayer games."

So, it appears as if they plan to make this a regular release. Seeking
clarification with upstream would be worth a shot.

Current is 0.8.11.

Wesnoth lead developer says, that with 0.8.9 they changed their
release cycle to concentrate on a single development stream. They plan
to continue with this until 1.0.

Though, it might be that due to its stability, 0.8.11 will be offered
as another "stable" release when its successor (0.8.12 most likely) is
released.

What do you think? Update FC3 Updates Testing and FC4 Development to 0.8.11?

Created attachment 113269 [details]
Wesnoth spec for 0.9.0

Well, 0.9.0 has been released now. Here's my spec candidate for it, what I'm
not so sure about does the split to separate -server package make sense
afterall...

Michael, thoughts?

FC4-devel at least but...

Have had a look...

Splitting off a -server package is reasonable as in some environments it's
common to ban server applications and the modifications they apply to a system
(e.g. new uid/gid, setuid, ...).

[...]

The added configure options

+          --with-server-uid=$(id -u) \
+          --with-server-gid=$(id -g) 

just set sane defaults during %install, but together with

+ %attr(0700, wesnothd, wesnothd) %{_localstatedir}/run/wesnothd

that doesn't work yet. Server binaries are owned by root.root and when run by an
ordinary user, the directory owned by wesnothd.wesnothd is inaccessible.

[...]

Needed to add "Buildrequires: libpng-devel" to get it compiled.

Moving the socket file (./src/server/server.cpp) from /var/run/wesnothd/socket
to $HOME/.wesnoth/socket would be a solution. With that, any unprivileged user
could start a server, which I think is desired for a game. And there should be
no need to create a "wesnothd" uid/gid, because a special user account at
run-time would not be needed.

Created attachment 113698 [details]
patch for server.cpp

[...]

Additionally, version 0.9.1 seems to look for libzipios++ for something:
http://sourceforge.net/projects/zipios

I'm not so sure I'd want to run a network game-server under my own user account
due to security implications - I certainly haven't audited the server code for
holes.

Changelog says about the zipios thing: "take advantage of libzipios++ if
available, to read cfg files, maps, images, sound effects, and fonts from zip
files." The game itself doesn't ship with any zip files so I don't consider it
critical but of course something that would be good to add sooner or later.

BTW Michael, would you care to take Wesnoth maintenance to yourself, at least
until I've gotten the bloody legal stuff with my company resolved (which can
take god-knows-how-long) to get CVS access? Trying to maintain stuff through
bugzilla isn't very ... nice :-/

Hmm... some observations:

# rpm -qpl wesnoth-0.8-2.i386.rpm | grep bin
/usr/bin/wesnoth
/usr/bin/wesnoth_editor
/usr/bin/wesnothd

Wesnoth for Fedora Extras FC3 includes the server, too, and it can be run by any
user, since it doesn't need write-access to any special directory.

With 0.9.0 this has not really changed, since the server doesn't do anything
with the configured uid/gid. "Make install" uses the values to set ownership of
the socket file in /var/run/..., so you would need to start the campaign server
with the same uid/gid. That's not suitable for packaging. Further, there is no
setup/init-script, which would start the server with the configured uid/gid.

Campaign server serves campaign files from user's home directory, where server
config file and uploaded campaigns are stored, too. That won't work with a
homeless system account "wesnothd". So, if campaign server were setuid
wesnothd.wesnothd, where would it keep its files?

Now, the main game binary has a built-in network server "Multiplayer -> Host
Networked Game".

Suggestion: Wait with a solution (e.g. setuid wesnothd + home directory +
nologin) until Wesnoth is considered stable/final and not include the servers.
Or relocate the fifo into home directory and leave it up to users, in which
account and on which machines to start network server processes.

What do you think?

Took the route of creating an initscript for wesnothd only, as one upstream
developer on IRC said campaign server can be dropped and is not considered
useful in the package.

In FC4, with latest release 0.9.2, but also 0.9.1, I see segfaults and "Illegal
instruction" (built with and without -O2, else default %optflags) when clicking
in some parts of the multi-player menus (e.g. the "Quit" button in "Join Game"
menu after connecting to a server). Need to install a couple of debuginfo
packages from Core (and also for SDL* packages), as all I get is:

(gdb) bt
#0  0x017fbe6c in ?? ()
#1  0x0026ab7a in __nptl_deallocate_tsd () from /lib/libpthread.so.0
#2  0x0026bb8e in start_thread () from /lib/libpthread.so.0
#3  0x00c79dee in clone () from /lib/libc.so.6

For reference:
https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg01074.html

[...]

Upstream has been informed about the crash experience with FC4. But like it
cannot be ruled out that it's some problem in Wesnoth, it cannot be ruled out
that it's due to GCC 4.0.0 and FC4. 

That's why we need to track this a bit via Fedora Extras Development and see
whether any GCC updates and/or rebuilds of SDL fix it.

Waiting for bug 161061 in libstdc++ to be fixed. FC4 and above.

Wesnoth 0.9.2 has been built for Fedora Extras Development. The binary packages
should work with Fedora Core 4 except for networked multi-player gaming. Once
there is a solution for the libstdc++ problem, an update for FC4 and FC3 would
be possible, but not before. So, feel free to give the devel package a try and
report any other issues you may find.

wesnoth-0.9.4-1.fc3 and wesnoth-0.9.4-1.fc4 have been built. May take a bit
before they show up in the repository.