Bug 233946 - (secondlife) Review Request: secondlife - The Second Life client
Review Request: secondlife - The Second Life client
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On: 229098 xmlrpc-epi 387991 403711 533384
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-26 04:50 EDT by Callum Lerwick
Modified: 2010-01-25 19:03 EST (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-21 01:30:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Callum Lerwick 2007-03-26 04:50:52 EDT
Spec URL: http://www.haxxed.com/rpms/secondlife/secondlife.spec
SRPM URL: http://www.haxxed.com/rpms/secondlife/secondlife-1.13.4.8-0.1.20070321a.src.rpm

Description:

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"... http://secondlife.com/corporate/trademark/
Comment 1 Peter Lemenkov 2007-03-26 06:00:06 EDT
> 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.
Comment 2 Rickey Moore 2007-03-26 20:56:43 EDT
Let me know when the server is ready! :) Ric
Comment 3 Peter Gordon 2007-03-26 22:25:47 EDT
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 01:04:39 EDT
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 16:14:35 EDT
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...
Comment 6 Rahul Sundaram 2007-04-14 10:21:02 EDT
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 10:45:22 EDT
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:
Comment 8 Callum Lerwick 2007-04-15 02:03:50 EDT
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...)
Comment 9 Neal Becker 2007-04-15 16:14:43 EDT
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
Comment 10 Callum Lerwick 2007-05-07 02:07:44 EDT
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@haxxed.com> 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...
Comment 11 Jeffrey C. Ollie 2007-06-22 00:45:46 EDT
I am unable to resolve www.haxxed.com...
Comment 12 Callum Lerwick 2007-06-22 21:30:03 EDT
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.
Comment 13 Marcel Edward Verhagen 2007-07-05 01:55:47 EDT
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 18:00:43 EDT
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 04:33:57 EDT
(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 06:47:39 EDT
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@haxxed.com> 1.17.2.0-1
- New upstream.

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

* Wed Jun 13 2007 Callum Lerwick <seg@haxxed.com> 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@haxxed.com> 1.16.0.5-1
- New upstream.

* Tue May 15 2007 Callum Lerwick <seg@haxxed.com> 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.
Comment 17 Hans de Goede 2007-07-07 08:55:49 EDT
(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-07 20:31:56 EDT
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@haxxed.com> 1.18.0.6-1
- New upstream.
Comment 19 Hans de Goede 2007-09-21 03:27:32 EDT
(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@haxxed.com> 1.18.0.6-1
> - 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-15 20:25:33 EST
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@haxxed.com> 1.18.4.3-1
- New upstream.
- Use opengl-game-wrapper.

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

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

* Sun Aug 05 2007 Callum Lerwick <seg@haxxed.com> 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.
Comment 21 Callum Lerwick 2007-11-19 18:50:47 EST
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 03:40:18 EST
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 04:03:07 EST
(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 16:09:54 EST
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 16:16:23 EST
(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 05:46:14 EST
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.
Comment 27 Callum Lerwick 2007-11-28 20:53:51 EST
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.
Comment 28 Callum Lerwick 2007-12-12 23:20:51 EST
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-22 22:30:47 EDT
Is there any update? The bug's been silent for months.
Comment 30 Callum Lerwick 2008-05-23 01:54:23 EDT
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 04:25:33 EDT
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 04:39:16 EDT
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-20 19:29:49 EST
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 18:02:37 EST
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 17:05:34 EDT
What's the status on this, Callum?
Comment 36 Bryan O'Sullivan 2009-10-21 01:30:41 EDT
Closing, as Callum de facto abandoned this a long time ago.
Comment 37 Arne Woerner 2009-11-03 11:04:39 EST
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

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