[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Update on slviewer package



Hey games-team,

Though I would check in with an update on slviewer the packaging of the
SecondLife client. (which you may have seen from the Games-commits spam
today).

I've continued to do a lot of work on this package, working directly
with upstream and getting a great deal of patches in to upstream's code
to ensure that the codebase will build on standard linux distributions
with the correct dependencies installed and also not have 64bit issues
and it was some of this work that got me opensource contributor of the
year from the company who produce Secondlife.

The current blockers are :-

* Mozlib - this is a long term blocker. Mozlib is a libary for rendering
webpages to memory buffers so that the page can be directly used as a
texture for GL apps or any other app needing a "picture" of a webpage.
It also permits sending back of mouse and keyboard events to interact
with the pages.

This has been the source of many problems, not least of, it was
requiring an increasingly patched xulrunner and with the release of
xulrunner-1.9 it broke completely. The replacement is being/been written
from scratch using webkit as the rendering engine. This appears to build
out of the box and so this is all very promising.

Once the new version is stable I will be attempting to get this into
Debian as a precursor to getting the secondlife package accepted. But
its actually a much more general purpose lib.

* curl with cares and non-blocking

There are some issues between secondlife and the two current libcurls
available on Debian. For optimum performance Secondlife really needs a
libcurl linked against c-ares with the non blocking option. Currently
the debian libcurl builds do not use c-ares due to some IPV6
unpleasantness, but i believe this may get fixed as/when c-ares gets
fixed in this area (which may in fact have happened already)

Minor issues

* Trademarks, this is a minor issue because 1) the artwork is made
dfsg-free by removing the trademarked images and 2) Upstream are
planning to remove the trademarked images themselves so future source
will contain only CC-SA-3.0 artwork. The binary the package produces is
also renamed omvviewer to avoid any possible trademark issues with the
original slviewer name.

* Git

I'm having various issues bringing the slviewer.git and
slviewer-artwork.git repositories upto date on Alioth. I think i'm
pretty much upto date, hence the commit spam, although a lot has been
caught as oversized messages.

But i'm having some issues, i'm loosing my SSH connection then not able
to reconnect for 5 minutes so it looks like some protection is kicking
in and filtering me out for a short time?

I've been developing on my own public git repository because we have
been extending the target of the packaging beyond debian and have
packages for ubuntu, arch and a gentoo overlay as well. Attempting to
merge in the upstream changes and the Debian branch history has lead to
the above git issues. I'm not really sure what to do here.

I'm changed my own repository to topgit based (for better or for worse),
but i've synchronised the slviewer.git on Alioth with the upstream
changes and the topgit generated patches. But in doing this i've not
managed to preserve the full commit history that my repository has.

So this leaves a few questions for the git layout -

Should I keep the slviewer.git and slviewer-artwork.git repositories on
alioth? under /git/pkg-games/ No one else from the games team is
currently contribution to them (but thats not a good reason to remove
them). But its also duplicate effort for me keeping two repositories
upto date? I'm also now in a complete mess where one repository is
generating its patches from topgit and the other is just having the
patch series imported and this is causing a merge conflict hell trying
to run the two repositories out of one place with separate git remotes.
I'm also wondering if i should hose the existing repositorie on Alioth
and start again from them so I at least have a common base so the merge
conflicts ease. I'm completely lost as to the best course of action here.

Regards

Robin











Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: