Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 233946 (secondlife) - Review Request: secondlife - The Second Life client
Summary: Review Request: secondlife - The Second Life client
Alias: secondlife
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
Depends On: 229098 xmlrpc-epi 387991 403711 533384
TreeView+ depends on / blocked
Reported: 2007-03-26 08:50 UTC by Callum Lerwick
Modified: 2010-01-26 00:03 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-10-21 05:30:41 UTC

Attachments (Terms of Use)

Description Callum Lerwick 2007-03-26 08:50:52 UTC
Spec URL:


The Second Life client for Linux, currently in alpha testing.

At long last, its ready for submission. Still tons of cleanup that could be done but I'll be tweaking it forever if I don't submit it now.

Probably needs a little work to compile on PPC, 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...) For one if compiling on linux it assumes i386 and tries to access the TSC with some assembler. Which it should never do anyway. Bleh.

The licensing on the source code seems to be in order. But I'm still unclear about the "artwork". In particular, I have no idea if their trademark policy is acceptable for Fedora. IANAL. Worst comes to worst, we have to strip out their trademarks and rename it "Fedora Alternate Existence"...

Comment 1 Peter Lemenkov 2007-03-26 10:00:06 UTC
> 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...)

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

Comment 2 Rickey Moore 2007-03-27 00:56:43 UTC
Let me know when the server is ready! :) Ric

Comment 3 Peter Gordon 2007-03-27 02:25:47 UTC
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).

Comment 4 Callum Lerwick 2007-03-27 05:04:39 UTC
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.

Comment 5 Callum Lerwick 2007-04-10 20:14:35 UTC
Okay, someone pointed out the license on an included font is probably not
acceptable for Fedora:

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...

Comment 6 Rahul Sundaram 2007-04-14 14:21:02 UTC
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. 

Comment 7 Neal Becker 2007-04-14 14:45:22 UTC
error: Failed build dependencies:
        openjpeg-devel is needed by secondlife-
        xmlrpc-epi-devel is needed by secondlife-
[nbecker@nbecker ~]$ sudo smart install openjpeg-devel xmlrpc-epi-devel

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

Comment 8 Callum Lerwick 2007-04-15 06:03:50 UTC
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 My net connection is down
which is hampering my testing and upload... (Borrowing the neighbor's wireless
on my laptop ATM...)

Comment 9 Neal Becker 2007-04-15 20:14:43 UTC
Attempted to build on x86_64 (fc6):

+ install -D -p -m 755 
indra/newview/secondlife-x86_64-bin-globalsyms /var/tmp/rpm/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)


Comment 10 Callum Lerwick 2007-05-07 06:07:44 UTC
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.

* Thu Apr 26 2007 Callum Lerwick <>
- 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...

Comment 11 Jeffrey C. Ollie 2007-06-22 04:45:46 UTC
I am unable to resolve

Comment 12 Callum Lerwick 2007-06-23 01:30:03 UTC
Argh, the server blew its power supply, looks like it finally got fixed. I've
got a package to upload once I get home.

Comment 13 Marcel Edward Verhagen 2007-07-05 05:55:47 UTC
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.

Comment 14 Callum Lerwick 2007-07-05 22:00:43 UTC
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.

Comment 15 Hans de Goede 2007-07-06 08:33:57 UTC
(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.

Comment 16 Callum Lerwick 2007-07-07 10:47:39 UTC
Heh, and once again, by the time I have a build ready, they've released a new
version. Oh well, here's

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

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

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

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

* Tue May 15 2007 Callum Lerwick <>
- 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.

Comment 17 Hans de Goede 2007-07-07 12:55:49 UTC
(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.

Comment 18 Callum Lerwick 2007-08-08 00:31:56 UTC

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

Comment 19 Hans de Goede 2007-09-21 07:27:32 UTC
(In reply to comment #18)
> * Thu Jul 12 2007 Callum Lerwick <>
> - New upstream.

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

Comment 20 Callum Lerwick 2007-11-16 01:25:33 UTC

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

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

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

* Sun Aug 05 2007 Callum Lerwick <>
- 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:

I have requested help to fix this.

Comment 21 Callum Lerwick 2007-11-19 23:50:47 UTC
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.

Comment 22 Hans de Goede 2007-11-20 08:40:18 UTC
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.

Comment 23 Ralf Corsepius 2007-11-20 09:03:07 UTC
(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.

Comment 24 Callum Lerwick 2007-11-20 21:09:54 UTC
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... :)

Comment 25 Hans de Goede 2007-11-20 21:16:23 UTC
(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.

Comment 26 Callum Lerwick 2007-11-22 10:46:14 UTC
Ah, yes Mesa upstream would be prudent if its truly a problem with Mesa. :)

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

Comment 27 Callum Lerwick 2007-11-29 01:53:51 UTC
Hmmm. I compiled up a copy of 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.

Comment 28 Callum Lerwick 2007-12-13 04:20:51 UTC
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?

Comment 29 Michel Alexandre Salim 2008-05-23 02:30:47 UTC
Is there any update? The bug's been silent for months.

Comment 30 Callum Lerwick 2008-05-23 05:54:23 UTC
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

Comment 31 Jason Tibbitts 2008-08-05 08:25:33 UTC
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.

Comment 32 Brennan Ashton 2008-08-05 08:39:16 UTC
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.

Comment 33 Jason Tibbitts 2008-11-21 00:29:49 UTC
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.

Comment 34 Callum Lerwick 2008-11-21 23:02:37 UTC
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...

Comment 35 Ian Weller 2009-07-04 21:05:34 UTC
What's the status on this, Callum?

Comment 36 Bryan O'Sullivan 2009-10-21 05:30:41 UTC
Closing, as Callum de facto abandoned this a long time ago.

Comment 37 Arne Woerner 2009-11-03 16:04:39 UTC
today i built a Snowglobe-x86_64- 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)... :-)


Note You need to log in before you can comment on or make changes to this bug.