|Summary:||Review Request: secondlife - The Second Life client|
|Product:||[Fedora] Fedora||Reporter:||Callum Lerwick <seg>|
|Component:||Package Review||Assignee:||Nobody's working on this, feel free to take it <nobody>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Package Reviews List <fedora-package-review>|
|Version:||rawhide||CC:||arne_woerner, bashton, bnocera, bos, bruno, ch.nolte, cweyl, dwmw2, farrellj, hdegoede, ian, jeff, kms, lemenkov, linuxdonald, luis, michel, mtasaka, nsoranzo, nushio, peter, wagnerlmm, wart, wayward4now|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-10-21 05:30:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||229098, 231809, 387991, 403711, 533384|
Description Callum Lerwick 2007-03-26 08:50:52 UTC
Spec URL: http://www.haxxed.com/rpms/secondlife/secondlife.spec SRPM URL: http://www.haxxed.com/rpms/secondlife/secondlife-18.104.22.168-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 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...) OMG! 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: 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 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-22.214.171.124-0.1.20070321a.x86_64 xmlrpc-epi-devel is needed by secondlife-126.96.36.199-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 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 188.8.131.52. 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-184.108.40.206-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 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. http://www.haxxed.com/rpms/secondlife/secondlife-220.127.116.11-1.src.rpm http://www.haxxed.com/rpms/secondlife/secondlife.spec * Thu Apr 26 2007 Callum Lerwick <firstname.lastname@example.org> 18.104.22.168-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 04:45:46 UTC
I am unable to resolve www.haxxed.com...
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 22.214.171.124 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 126.96.36.199: http://www.haxxed.com/rpms/secondlife/secondlife-188.8.131.52-1.fc7.src.rpm http://www.haxxed.com/rpms/secondlife/secondlife.spec * Wed Jun 27 2007 Callum Lerwick <email@example.com> 184.108.40.206-1 - New upstream. * Tue Jun 26 2007 Callum Lerwick <firstname.lastname@example.org> 220.127.116.11-1 - New upstream. * Wed Jun 13 2007 Callum Lerwick <email@example.com> 18.104.22.168-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 <firstname.lastname@example.org> 22.214.171.124-1 - New upstream. * Tue May 15 2007 Callum Lerwick <email@example.com> 126.96.36.199-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 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
http://www.haxxed.com/rpms/secondlife/secondlife.spec http://www.haxxed.com/rpms/secondlife/secondlife-188.8.131.52-1.fc7.src.rpm * Thu Jul 12 2007 Callum Lerwick <firstname.lastname@example.org> 184.108.40.206-1 - New upstream.
Comment 19 Hans de Goede 2007-09-21 07:27:32 UTC
(In reply to comment #18) > http://www.haxxed.com/rpms/secondlife/secondlife.spec > http://www.haxxed.com/rpms/secondlife/secondlife-220.127.116.11-1.fc7.src.rpm > > * Thu Jul 12 2007 Callum Lerwick <email@example.com> 18.104.22.168-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-16 01:25:33 UTC
http://www.haxxed.com/rpms/secondlife/secondlife.spec http://www.haxxed.com/rpms/secondlife/secondlife-22.214.171.124-1.fc7.src.rpm * Tue Nov 13 2007 Callum Lerwick <firstname.lastname@example.org> 126.96.36.199-1 - New upstream. - Use opengl-game-wrapper. * Wed Oct 31 2007 Callum Lerwick <email@example.com> 188.8.131.52-1 - New upstream. * Fri Oct 19 2007 Callum Lerwick <firstname.lastname@example.org> 184.108.40.206-1 - New upstream. * Sun Aug 05 2007 Callum Lerwick <email@example.com> 220.127.116.11-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 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 18.104.22.168 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 22.214.171.124 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-126.96.36.199.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