> I don't have a powerful enough PPC machine to compile or run it. (Warning: 
> You'll want at least 2gb of RAM if you don't want to watch your machine swap for
> several hours while compiling...)

OMG!
In any case I'll try to compile it at my Mac Mini.

Let me know when the server is ready! :) Ric

Is anything in the artwork tarball arch-dependent? If not, I'd recommend
packaging it as a noarch and fully separate (i.e., different SRPM)
secondlife-data package and making it a dependency of this; that will allow for
smoother upgrades (since the data may be a significantly large but unnecessary
portion of the update of a bugfix package).

I'm hesitant to bother splitting it, mainly on the basis that they keep
releasing a new matching versioned artwork tarball with every source release.
I've not got around to checking if they're even any different. We need to talk
to LL about versioning the artwork seperately from the source, if they're in
fact not changing.

Okay, someone pointed out the license on an included font is probably not
acceptable for Fedora:

http://jira.secondlife.com/browse/VWR-408

It has a no modification clause and a funky commercial distribution clause. How
should we handle this? We might be able to convince upstream to change the
license, otherwise we have to patch slviewer to just use DejaVu Sans Mono or
something. Wonder how hard it would be to just get it to use xft...

Please contact upstream with a clear recommendation to relicense the font or use
a   open font instead mentioning that this is a requirement for this package to
be in Fedora. 

If upstream doesn't want to change this, patch it. 

error: Failed build dependencies:
        openjpeg-devel is needed by secondlife-1.13.4.8-0.1.20070321a.x86_64
        xmlrpc-epi-devel is needed by secondlife-1.13.4.8-0.1.20070321a.x86_64
[nbecker@nbecker ~]$ sudo smart install openjpeg-devel xmlrpc-epi-devel
[...]

error: 'openjpeg-devel' matches no packages. Suggestions:

Yes, you need those two libraries, which are also submitted by me and are under
review. Check the bug deps. :)

I did up a patch to use DejaVu instead of the included fonts. Font metrics are a
bit off but it works. Also an update to 1.14.0.1. My net connection is down
which is hampering my testing and upload... (Borrowing the neighbor's wireless
on my laptop ATM...)

Attempted to build on x86_64 (fc6):
[...]

+ install -D -p -m 755 
indra/newview/secondlife-x86_64-bin-globalsyms /var/tmp/rpm/secondlife-1.13.4.8-0.1.20070321a-root-nbecker/usr/bin/secondlife
install: cannot stat `indra/newview/secondlife-x86_64-bin-globalsyms': No such 
file or directory
error: Bad exit status from /var/tmp/rpm/rpm-tmp.2087 (%install)


RP

Argh. So the upgrade to debian 4.0 on my server didn't go so well, among other
things but I'm back in business again for now.

http://www.haxxed.com/rpms/secondlife/secondlife-1.15.0.2-1.src.rpm
http://www.haxxed.com/rpms/secondlife/secondlife.spec

* Thu Apr 26 2007 Callum Lerwick <seg> 1.15.0.2-1
- New upstream.
- Non-redistributable fonts are no longer included, substitute DejaVu LGC
  for now.

Upstream pulled the fonts from the source tarball, so that's no longer a
problem. I've patched it to use DejaVu Sans Condensed which matches the original
font fairly well. The metrics on the mono font are still kind of off, but you
really only see this if you use the debug panels. (ctrl-shift-[1-4])

Unfortunately its hardwired to require DejaVu LGC, full DejaVu would be better,
for full unicode support but I figure LGC exists for a reason. I don't know if
we should force everyone to install full DejaVu. We could set a fallback to full
DejaVu if installed. This is all hacky, in the long run it would be nice if we
could patch it to use fontconfig and/or pango or something...

I am unable to resolve www.haxxed.com...

Argh, the server blew its power supply, looks like it finally got fixed. I've
got a 1.17.0.12 package to upload once I get home.

I have tried the 64 bit version. 
It is faster than the 32 bit although a bit more crashie.

When will the secondlife 64 bit client be avaliable in a repository ?
The secondlife.repo doensn't work. I get a missing respond.xml error

I made a new 64bit rpm for the xmlrpc-eli to get the 64 bit secondlife client 
to install.

Heh, I get so involved in nailing down bugs I keep forgetting I haven't uploaded
a build in a while. I seem to have nailed the avatar texture baking problem
which was the last major annoyance in the open source build.

(In reply to comment #14)
> Heh, I get so involved in nailing down bugs I keep forgetting I haven't uploaded
> a build in a while. I seem to have nailed the avatar texture baking problem
> which was the last major annoyance in the open source build.

Thats very good to hear, any chance you can create update patches of the client
and all its deps, and post URL's to the reviews?

Then we can review them and hopefully get secondlife into Fedora soon.

Heh, and once again, by the time I have a build ready, they've released a new
version. Oh well, here's 1.17.2.0:

http://www.haxxed.com/rpms/secondlife/secondlife-1.17.2.0-1.fc7.src.rpm
http://www.haxxed.com/rpms/secondlife/secondlife.spec

* Wed Jun 27 2007 Callum Lerwick <seg> 1.17.2.0-1
- New upstream.

* Tue Jun 26 2007 Callum Lerwick <seg> 1.17.1.0-1
- New upstream.

* Wed Jun 13 2007 Callum Lerwick <seg> 1.17.0.12-1
- New upstream.
- Compile for a minimum of a Pentium II on i386.
- Include patch for OpenAL audio support.

* Sat May 26 2007 Callum Lerwick <seg> 1.16.0.5-1
- New upstream.

* Tue May 15 2007 Callum Lerwick <seg> 1.15.1.3-1
- New upstream.


Is there a problem with the deps? AFAIK they should still work.

And how controversial is compiling for a minimum of a PII on i386? Official
upstream requirements are a minimum of a PIII, the only reason I don't compile
for PIII is the Athlon Thunderbird which lacks SSE, and is also supported upstream.

(In reply to comment #16)
> Is there a problem with the deps? AFAIK they should still work.
> 

The problem with the deps is that they both have had a detailed review, which
stipulates a few small things to fix, and you haven't responded. If yoou could
create new version of each fixing the issues raised during review, then they can
get approved and into Fedora, which is kinda a must in order to get secondlife
itself into Fedora.

http://www.haxxed.com/rpms/secondlife/secondlife.spec
http://www.haxxed.com/rpms/secondlife/secondlife-1.18.0.6-1.fc7.src.rpm

* Thu Jul 12 2007 Callum Lerwick <seg> 1.18.0.6-1
- New upstream.

(In reply to comment #18)
> http://www.haxxed.com/rpms/secondlife/secondlife.spec
> http://www.haxxed.com/rpms/secondlife/secondlife-1.18.0.6-1.fc7.src.rpm
> 
> * Thu Jul 12 2007 Callum Lerwick <seg> 1.18.0.6-1
> - New upstream.

Callum, I wouldn't mind reviewing this, but first the dependencies need to get
taken care of.

http://www.haxxed.com/rpms/secondlife/secondlife.spec
http://www.haxxed.com/rpms/secondlife/secondlife-1.18.4.3-1.fc7.src.rpm

* Tue Nov 13 2007 Callum Lerwick <seg> 1.18.4.3-1
- New upstream.
- Use opengl-game-wrapper.

* Wed Oct 31 2007 Callum Lerwick <seg> 1.18.4.1-1
- New upstream.

* Fri Oct 19 2007 Callum Lerwick <seg> 1.18.3.5-1
- New upstream.

* Sun Aug 05 2007 Callum Lerwick <seg> 1.18.1.2-1
- New upstream.


Note that Fedora 8 curl completely breaks Second Life, you can not log in. The
switch to NSS seems to have broken it. As a workaround you can revert your curl
package to an OpenSSL based one as mentioned in this post:

http://www.redhat.com/archives/fedora-devel-announce/2007-August/msg00017.html

I have requested help to fix this.

bz387991 seems to be a fix for the curl bug. However I'm running into more
breakage in Fedora 8. I briefly experimented with updating to Mesa 7 in Fedora
7, which also required updating to expat 2. But I ran into problems with SL
rapidly eating up all RAM and choking the machine. It only seemed to affect
x86_64, and turning off VBO seemed to be a workaround. Reverting back to Fedora
7 mesa/expat fixed it as well.

Now with Fedora 8 final I seem to be once again seeing the same bug. This time
its happening on i386, and turning off VBO doesn't seem to help. I haven't dared
upgrade my x86_64 machines to F8 because of this. My attempts to use massif to
see where this memory is going have been rather futile, it slows the client down
too much.

So there seems to be a severe memory leak somewhere, likely something to do with
Mesa and/or expat 2.x.

My bet would be the problem is with Mesa, I've several problems (maniadrive,
trackballs) with Mesa-7 too. I think the best solution is to file a bug upstream.

(In reply to comment #22)
> My bet would be the problem is with Mesa, I've several problems (maniadrive,
> trackballs) with Mesa-7 too. 
FWIW: I would not be so sure. I am observing quite a number of severe problems
with my GL-based packages (e.g. Inventor, Coin2) on F8 even if not using Mesa-GL
and using nvidia-GL, instead.

The worst breakdowns so far had been complete kernel hangers when running GL
apps, but I've also seen X-server lockups.

Unless the bug shows up in the upstream binary builds, upstream seems unlikely
to be particularly helpful. The Windlight viewer seems to work fine.

Ultimately, I'd like to just push forward with getting SL merged so that we can
get the maximum number of eyes on the bugs. OpenJPEG is in the testing repo
right now. Now I have to get xmlrpc-epi done... :)

(In reply to comment #24)
> Unless the bug shows up in the upstream binary builds, upstream seems unlikely
> to be particularly helpful. The Windlight viewer seems to work fine.
> 

I'm sorry I should have been more clear, I meant mesa upstream not SL upstream.

Ah, yes Mesa upstream would be prudent if its truly a problem with Mesa. :)

One thing of note, is that slviewer 1.18.0.6 didn't seem to have this problem,
though I haven't tried it with Fedora 8.

Hmmm. I compiled up a copy of 1.18.0.6 on Fedora 8 and I see the leak there now
too. I see this on my Intel 830M laptop as well so this does not seem to be
unique to the r300 driver my other machines are using. I'm now fairly convinced
this is in fact a problem with Mesa 7.

Ack. Turns out the massive leakage was ultimately triggered by an OpenJPEG bug,
which has been fixed. A fixed OpenJPEG should be in testing now/soon. I'm still
unclear on what exactly was going on. Leaking texture handles or something?

Is there any update? The bug's been silent for months.

Hrm I'm slacking. I've been busy with stuff, and falling behind the debian guys.
:) Build haven't been as stable as I'd like, but it looks like the texture
buggyness is finally starting to get fixed upstream.

My lease is up at the end of the month so I'm currently in the middle of moving
to another apartment. All my desktop machines are packed up so I won't really be
able to do any packaging related stuff for the next month or so. So this bug
will have to hibernate for another month or so. :P

Erm, why was this ticket assigned to the person who submitted it?  Review tickets should be assigned to the person who is reviewing, or to nobody if they are not being reviewed.

Sorry, I figured it was there responsibility to manage the bug as it is there package being reviewed. We are working to move bugs out of New and into there respective categories in order to keep fedora moving along, and allow BugZilla to work properly.

Does this do anything at all without xmlrpc-epi?  I'm going to assume not and mark it as not being ready; please clear the whiteboard if things progress to a point where it can be reviewed.

Yes, xmlrpc-epi is required. I'm finally settled and getting back to hacking code so I may be reviving my Second Life efforts soon. I'm hacking on OpenJPEG at the moment...

What's the status on this, Callum?

Closing, as Callum de facto abandoned this a long time ago.

today i built a Snowglobe-x86_64-1.1.3.0.tar.bz2 package without the embedded www browser support (llmozlib2)... took me some hours, but it was quite easy (mostly some unusual notations (like "#define ABC() def" or "if (a || b && c)")... and bad include paths (-I)...)...

it likes pulseaudio with openal-soft...

but voice still works with the original 32-bit voice binary (SLVoice), which doesnt need so many 32-bit libraries, so that it doesnt take too much main mem...

i hope that my 2GiB main mem will be sufficient now... the 32 bit client sometimes almost halted the whole box due to not enough memory (swapping made things worse)... :-)

-arne