Request for help: Secondlife viewer

[Robin Cornelius]

Paul TBBle Hampson wrote:

> OK, I've finally grabbed your source packages, but I dunno if I'll have
> time to look at them tonight, in order to be somewhat more helpful in
> this discussion. ^_^

Cool, thanks. Which version have you grabbed. Is it from the
apt-repository at cornelius.demon.co.uk? or the direct downloads on
byteme.org (which i *must* remove). I am trying to keep the
apt-repository on cornelius.demon.co.uk as a staging area for latest
versions of both our packages.

The latest version is testing against the 1.18.5.0 rc.

> 
> OK, I lied. I've had a quick look. I see that 44-pkgconfig-me-harder
> was dropped, and 21_VWR_2488_Standalone_build_fixes approaches the
> gstreamer issue a different way. However, the latter adds gstreamer
> and openal as fixed pkgconfig packages, even though they are (or
> should be...) optional.
> 
> In fact, a quick look at your OpenAL patch suggests that OpenAL
> becomes mandatory, and FMOD support is removed? Unless this is
> a direction upstream has indicated they intend to go, then it
> would be better if OpenAL was optional (at compile time, like FMOD)
> although I haven't looked at the llaudio code so I can't say if
> it's actually non-trivial.
> 
> Either way, gstreamer is definately optional to the build process,
> and the 21_VWR_2488_Standalone_build_fixes patch doesn't handle
> that properly, nor does it avoid repeating pkgconfig's work in
> the if gstreamer: section that the 44-pkgconfig-me-harder patch
> did.


Ok so the code from 44-pkgconfig-me-harder should be used to make
gstreamr optional again and I assume llmozlib can be made optional as
well. As for OpenAL I am expecting updates here soon, Seg has been doing
some work so it may be able to drop in as an optional package again soon

> 
> (This just became a longer look... -_-)
> 
> There's no mention in the changelog, but 42 appears to have been dropped
> since upstream now refers to the library as xmlrpc-epi as well. I only
> noticed this while trying to work out why 40-know-your-distribution had
> been dropped.
> 
> I'm pretty sure I mentioned this before (about openjpeg?) but you've got
> numbering clashes in your dpatches.
> 
> Also, don't forget the Jira URL for patches pulled directly from Jira.

Yea, haven't done any changes since your last breif look other that
going to 1.18.5.0. I know i need to update a lot there.

> 
> You've misspelled updating in debian/copyright, and fails in your 20_
> dpatch name. Also, you appear to be missing the DEBFULLNAME and DEBEMAIL
> environment variables.

Ok add to pile to be updated.

> 
> I see they've added a $LicenseInfo:firstyear=2004&license=viewergpl$
> to their internal SVN repository.
> 
> Anyway, hope that helps. ^_^ I'll look forward to having an SVN
> repo, and see about getting that PowerPC box up.

As for SVN should we use the games SVN area on alioth? This gives the
advantage that DD's can join in as they wan to as well. I will ask the
games team driectly about this (unless they pickup on this here)

> 
> Oh, and are you using dpatch-cowdancer-patch to edit the dpatches?
> It actually came about because dpatch-edit-patch on the slviewer
> source was painfully slow on my old laptop. ^_^

No, been playing the hardway, i have been spending more time recently
fighting packageing, dpatch and pbuilder as they are quite new to me so
it has been a bit of an uphill start but i think i am just getting there
now.

> 
> Hmm. Just occurred to me to look at the .py files, and sure enough,
> indra/lib/python/indra/__init__.py has an 'internal' copyright header.
> 
> No contents though, as its mere existence is its function. Still worth
> poking upstream. (I'll have a look later at adapting headeraudit.pl to
> handle python files. Or possibly a new version.)
> 
> I've attached an updated headeraudit.pl to take advantage of the new
> regularity in the copyright headers. It gives a clean report except
> indra/win_crash_logger/resource.h, which is a generated file ala the
> other resource.h in the debian/rules headeraudit rule.
> 
> It also can process the .py files. And it knows the MIT license header
> LL are using for them.
> 
> Current failures (ignoring incorrect @file labels) are:
> indra/lib/python/indra/__init__.py is under 'internal' license
> indra/lib/python/indra/ipc/httputil.py

Ok cool, thanks for that.

> 
> Note that debian/copyright needs updating, now that nothing fails the
> audit. (I note that the one file that failed the audit with an entirely
> different license before has had the LL license prepended to the old
> one.)
> 
> Oh, and add yourself to the copyright of the packaging. ^_^

Oh, yea will do.

This really needs a version control repository such as SVN!


Regards

Robin







-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20071118/3edb7907/attachment.pgp