Re: [opensource-dev] LGPL violation
On Wed, Oct 27, 2010 at 10:17:01AM -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-10-23 7:27, Carlo Wood wrote:
> > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed
> > library statically against a proprietary executable provided you
> > provide the object code or source code of the work that uses the library.
>
> Not correct. LGPL code may be linked to other source without having the
> viral effect of requiring that other source also be published as open
> source. LGPL _does_ require that if any changes are made to the source
> under that license, then those changes (and the original sources) must
> be open and available either as LGPL or as GPL.
You state pretty firmly, while I believe you are in error.
You are NOT allowed to link statically with an LGPL-ed library unless you
provide the means for the user to relink the library, for example by
providing the .o (object) files that it is linked with.
>From many available links, let me quote an answer from
http://answers.google.com/answers/threadview/id/439136.html:
Q2a: What is the implication of static linking?
A2a: You need to comply with the license requirements. Eban Moglen in
http://www.spinics.net/lists/xf/msg02311.html
indicates that you are producing a "derivative work" of the code in
the library. In the United States the US Copyright Office states at
http://www.copyright.gov/circs/circ14.html
A "derivative work," that is, a work that is based on (or derived
from) one or more already existing works ... [copyright statements].
Both of those statements are pretty clear so section 6 of the LGPL
applies. Note that you can distribute (6a)
... [your work] as object code and/or source code, so that the user
can modify the Library and then relink to produce a modified
executable containing the modified Library
You can thus distribute object files (and protect your source code)
and still comply with the requirements of the LGPL.
However, others (in particular, Richard Stallman) does not necessarily
interpret the LGPL in this way. I strongly recommend you contact the
copyright holder prior to building a statically linked application for
distribution as a commercial product.
In this case, you'd have to contact Troll Tech and ask them if even
this is allowed, but at the very least you can NOT distribute
libmedia_plugin_webkit.{sp,dll,dylib}, which is statically linked
with Qt, without at least providing the object files that it exists
of (in addition to Qt), that you are the copyright holder of.
I think this is extremely logical: The user must at all times
be able to get the source code of the LGPL-ed library, change it,
and *RELINK* it with the application he or she is using.
The BSD guys have a different view though (just to make clear that
you completely orthogonal view really ought to be backed up by one
of your lawyers). Quoting
http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html#ORIGINS-LGPL
(where 'glibc' is used as an example of an LGPL-ed library):
If you statically link an application with glibc, such as is often
required in embedded systems, you cannot keep your application proprietary,
that is, the source must be released. Both the GPL and LGPL require
any modifications to the code directly under the license to be released.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On 10/28/2010 06:29, Carlo Wood wrote:
libmedia_plugin_webkit.{sp,dll,dylib}
Make sure you quote examples of static linking when you're talking about
static linking :)
Dynamically loaded libraries (that is, after all, what "dll" is an
abbreviation for) are by definition not statically linked. if they were
statically linked you wouldnt need the .dll, the .so or the .dylib file
because the object code would have been incorporated into the binary at
link time. Statically linked progs dont require external library files,
dynamically linked ones do. Thats the reason that on Solaris systems
roots default shell is /sbin/sh rather than /bin/sh - its statically
linked so that even if the lib loader is hosed the sysadmin can still
get to a working shell to fix it. (historically, statically linked progs
went in /sbin not /bin - not always a convention honored these days
since so few progs are ever completely statically linked any more but in
this case it was)
Now get off my lawn ;)
Dave
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [META] User stories and issue tracker readability
To my understanding here is the following: 1. The main jiras (VWR, WEB, SVC) are for general issues basically no user story. 2. When they get pulled to a particular teams jira ( STORM, DN, MESH ) they then get converted to a 'story' with sub tasks relating to that 'story' This is my twp cents worth on this. From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Boroondas Gupte Sent: Saturday, October 23, 2010 12:01 PM To: Second Life Open Source Developer Mailing List Subject: [opensource-dev] [META] User stories and issue tracker readability As a user of the Second Life issue tracker (jira) who often sorts or searches through others' issues, I'd like people creating or editing issues to place the (sometimes lengthy) user stories into the Description field, not the Summary field. The summary should be as short as possible while still conveying what the issue is about. The role for whom the issue matters (i.e. "As a ..., I ...") and the specifics of the motivation / reason for the issue are important when examining a single issue, but aren't too helpful when looking for duplicates of other issues or when searching for already existing issues of a wish or problem you have. Even worse, because the space for displaying the summary is very limited in some of the greenhopper views, you often only see the "As a ..." part while the rest gets cut off, so you can't tell at one glance what an issue being discussed is about at all. Think of an issue as a little book. The story you want to tell belongs to the inside (the description). On the cover (summary), you want the story's title (catchy and ideally different from the title of other books), not the first chapter. What do you think? Cheers, Boroondas _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1144 / Virus Database: 422/3214 - Release Date: 10/23/10 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> On 10/28/2010 06:29, Carlo Wood wrote:
> libmedia_plugin_webkit.{sp,dll,dylib}
>
> Make sure you quote examples of static linking when you're talking about
> static linking :)
Make sure you read carefully what I say and understand it before
talking about wrong examples :)
libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
the Qt libs (as in, linked with .a).
Thus:
Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
==> LL*.o must be made public (or their source code), or
libmedia_plugin_webkit.so cannot be shipped.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
Actually the Qt wbekit source that LL uses is available as I had to
completely rebuild the set of libs on my system when I was working on
snowglobe using visual studio 2008 as the lib provided by LL caused an issue
when starting the viewer after being build due to an manifest
incompatibility issue.
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Carlo Wood
Sent: Thursday, October 28, 2010 11:52 AM
To: Dave Booth
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] LGPL violation
On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> On 10/28/2010 06:29, Carlo Wood wrote:
> libmedia_plugin_webkit.{sp,dll,dylib}
>
> Make sure you quote examples of static linking when you're talking about
> static linking :)
Make sure you read carefully what I say and understand it before
talking about wrong examples :)
libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
the Qt libs (as in, linked with .a).
Thus:
Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
==> LL*.o must be made public (or their source code), or
libmedia_plugin_webkit.so cannot be shipped.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges
_
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
There is a static component that is linked when linking to dynamic
libraries, however that is present mostly to inform the compiler on what the
ABI is, or how your compiled code is expected to interact with the DLL. It
is very possible to write a piece of code that explicitly loads the library
by name and manually builds calls to it. In fact, it's likely possible to
compile a program intended to run with a .dll without any related files
being on the machine at the time.
On Thu, Oct 28, 2010 at 8:52 AM, Carlo Wood wrote:
> On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> > On 10/28/2010 06:29, Carlo Wood wrote:
> > libmedia_plugin_webkit.{sp,dll,dylib}
> >
> > Make sure you quote examples of static linking when you're talking about
> > static linking :)
>
> Make sure you read carefully what I say and understand it before
> talking about wrong examples :)
>
> libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
> the Qt libs (as in, linked with .a).
>
> Thus:
>
> Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
>
> ==> LL*.o must be made public (or their source code), or
> libmedia_plugin_webkit.so cannot be shipped.
>
> --
> Carlo Wood
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On 10/28/10, Erik Anderson wrote: > There is a static component that is linked when linking to dynamic > libraries, however that is present mostly to inform the compiler on what the > ABI is, or how your compiled code is expected to interact with the DLL. It > is very possible to write a piece of code that explicitly loads the library > by name and manually builds calls to it. In fact, it's likely possible to > compile a program intended to run with a .dll without any related files > being on the machine at the time. Yeah, but that's not what we're talking about. libmedia_plugin_webkit.so is in fact linked statically with various Qt libraries - the entirety of the code for those Qt libraries is incorporated into libmedia_plugin_webkit.so by the linker at compile time, not just a stub. The same happens with libmedia_plugin_webkit.a and libmedia_plugin_webkit.dylib. I'm not sure exactly why Linden Lab decided to do this - it's not a common thing to do and getting it to work right requires a certain amount of mucking with the build system, since static libraries normally aren't compiled with options that allow them to be included in a shared library - but do it they did. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] On Live, SL via Cloud Computing
Seems like an excellent thought to me. Someone should proto-type this and see how it feels. $60/yr is less than the cost of a new GPU. lee On Wed, Oct 27, 2010 at 10:53 PM, Stickman wrote: > Had a thought, figured I'd share it in case someone with authority > wanted to explore the topic. > > On Live (http://www.onlive.com/) is a cloud computing gaming service. > You open up the client and their computers run the game and graphics > and stream the video to you while accepting your controls. It means > you can run games on systems that otherwise wouldn't run them. > > Pros: > -Less powerful computers can run SL on high settings > -Collaboration could result in cached or close asset data for super > fast object and texture loading > > Cons: > -$5/month subscription fee per user (Premium option?) > -Requires high bandwidth (3mbit) connection > -Probably consumes more bandwidth than SL itself would > > The big turn off for On Live to me is a monthly fee combined with full > price video games combined with "don't pay for a year, we delete your > account including your purchase record." But those cons wouldn't apply > when dealing with Second Life through this medium. > > Just throwing that out there. > > Stickman > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] problems with dev build 2.4.0 (213153)
I installed the windows version, and it keeps tripping up on both 32 and 64 bit windows 7 versions as well as on XP pro. specifically it keeps triggering the "this program may not have installed correctly" windows alert. It seems to be a bit sluggish as well. I reinstalled to no avail. Any ideas if theres a bug in the build or? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
On 10/27/2010 10:45 AM, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files > behind that were created by the program automatically, such as log files. Au contraire contraire. MANY people get VERY upset when an installer deletes files that belong to them that they directed the program to create, either explicitly, or automatically via an explicit setting. I have the original viewer 2 installed right now and am not going to uninstall it until I am DAMN SURE I have backed up my entire profile, specifically because of this asinine design flaw. If I didn't already know about it, I would be ROYALLY pissed off when it deleted years' worth of accumulated data; MY data. Despite having backups, there still will be incremental loss (data since last backup), and the hassle of having to restore said data. Other people aren't so lucky, not knowing to back up said profile data, or simply not doing backups (yeah, their risk, but there is NO call to intentionally manifest that failure in code). > It's simply not true that the uninstaller shouldn't remove anything in the > profile -- I have worked at multiple companies where leaving behind any > breadcrumbs (anything that wasn't created by File Save) after an uninstall > was considered a major bug. Then that is multiple companies which promoted a SERIOUS installer design paradigm flaw. I can't say I envy you there. Of the hundreds of customers I have developed software for over the past 3 decades, if I had implemented such a design flaw in my uninstallers, I would have lost a lot of money, and potentially been sued by at least a couple of them. (btw, aren't anecdotal stories acting as appeal to authority logical fallacies fun?) Look, this isn't hard to grok; it really isn't. Any collection of data which is created by or at the behest of the user is considered "user data". Implementations of a proper installer paradigm should NEVER *EVER* touch user data, either automatically or by default WITHOUT the full knowledge and consent of the user. That includes things like chatlogs, user-created folders underneath the program directory, user preferences, etc. This does not apply to things like temporary files, cache files/folders, or program data (because none of that is "user data"). An uninstaller also should inform the user of any files that it left behind, where, and why. Give the user information and control, and you don't have "very upset" users. Maybe "mildly annoyed" users, but not "I want to throttle the idiot developer that did this to me" users. At MOST, an uninstaller, if it is hell-bent on trying to clean up *COMPLETELY* after itself, *must* inform the user that it wants to cleanup his/her user data, explain EXACTLY and IN DETAIL what is going to be cleaned, and leave the default for the option to NO (as in "don't delete my data!"). This is simply proper (un)installer design, and I am amazed that so many developers simply "don't get it", to the pain of their users (including myself). Deleting data is FAR more serious of an issue than leaving data behind. Once it is gone, it is gone; if it is left behind, the user can clean it up themselves. Anger from lost data >>> annoyance of having to break out the data dustbuster. > Now I do think we can try do better; asking about deletion is on the > Snowstorm backlog. I sure hope so. <.< > Installers are always tricky and hard to test, and very often the uninstaller > comes "for free" with writing the installer. It's also specialized, > platform-specific code, sometimes in a strange language, so it's not easy to > find devs who want to work on it. They are not nearly as tricky or hard to test as code itself. Yeah, the uninstaller is often auto-generated by the installer generator, but to not then go through it with a fine-toothed comb for verification and add application-specific changes to the uninstall script is just laziness, pure and simple. The "strange language" is often fairly simplistic and easy to manipulate with only a modicum of time and effort put into learning it. I would be extremely surprised to learn that there isn't at least one "installer expert" at LL, whose primary job function is building and testing installer packages (note I said "primary", not "sole"; let's not go there). > There's work going on right now that will probably affect this, and we'll > make sure this is considered. It needs more than consideration; it needs to be done, period. It's improper and incorrect, it is a design flaw, and it needs to be fixed ASAP before it does any more damage to user data. --TL ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
getting back to what i said 1 the uninstaller should state that it is removing the profile data (best thing to do would be to zip it and put it in a folder on the desktop) 2 TPVs should by default not use the default secondlife profile folder (i would bet that 40% of SL/TPV problems could be solved by this simple step) 3 the recycle bin is a gamble anyway and may not be safe to use (2 gigs of profile data and a 1 gig recycle bin size = chunks of missing data) -- Robert L Martin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] problems with dev build 2.4.0 (213153)
Actually from what Merov said @ today's scrum meeting it seems that the TC system might not have built that version right so that could be causing your problems. From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Erin Mallory Sent: Thursday, October 28, 2010 2:19 PM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] problems with dev build 2.4.0 (213153) I installed the windows version, and it keeps tripping up on both 32 and 64 bit windows 7 versions as well as on XP pro. specifically it keeps triggering the "this program may not have installed correctly" windows alert. It seems to be a bit sluggish as well. I reinstalled to no avail. Any ideas if theres a bug in the build or? _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] On Live, SL via Cloud Computing
Has anyone on this list actually tried OnLive? What's the ping time and the general responsiveness like? People are always hyping these server-side-rendering solutions as the Next Big Thing, but so far I don't see it... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] On Live, SL via Cloud Computing
On 10/27/2010 10:53 PM, Stickman wrote: > Had a thought, figured I'd share it in case someone with authority > wanted to explore the topic. I'm not an authority, but I have explored it a bit. > On Live (http://www.onlive.com/) is a cloud computing gaming service. > You open up the client and their computers run the game and graphics > and stream the video to you while accepting your controls. It means > you can run games on systems that otherwise wouldn't run them. > It's an iteration on an old idea. Render the scene, stream it to the user, accept user input back to the server to render the next scene, etc. It's always been a huge boondoggle because of the amount of bandwidth it takes, loss of image fidelity, and the control lag. > Pros: > -Less powerful computers can run SL on high settings It still requires a fairly beefy computer to run the decoding in high image quality with high frame rates, which is pretty much a requirement to avoid image artifacting. > Cons: > -$5/month subscription fee per user (Premium option?) > -Requires high bandwidth (3mbit) connection > -Probably consumes more bandwidth than SL itself would -Control lag; even though they claim it is "good enough" for FPS games, many FPS players who have tried it out report serious latency in control response, turning them off of it. -Image quality issues: viewing a virtual world as a compressed movie will have significantly noticeable image quality issues (and has been noted in reviews of the service). My personal take on it (and has been since the mid-90s, when this concept was first proposed) is "no thanks". I prefer to use the horsepower of my system to generate the world, especially since that horsepower is still ever-increasing on a geometric scale, and getting cheaper all the time. It also isn't that hard to keep SL's platform requirements within the grasp of older hardware for a good long while. --TL ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] On Live, SL via Cloud Computing
I have an OnLive Founders account, and it is actually pretty good for response time. The downside of it right now is the small game library and the fact that you have to use an XBOX360 controller if you want to use a joystick. On Thu, Oct 28, 2010 at 12:57 PM, Dale Innis wrote: > Has anyone on this list actually tried OnLive? What's the ping time > and the general responsiveness like? > > People are always hyping these server-side-rendering solutions as the > Next Big Thing, but so far I don't see it... > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
It might be more logical to store the chat logs - or perhaps a copy of the chat logs - in the "My Documents" folder, or operating system equivalent. The recycle bin might be a gamble, but it has better odds of allowing data restoration that not putting the deleted files in the recycle bin, doesn't it? Putting deleted chat log files in the recycle bin is not meant to exclude other needed improvements such as not deleted the files in the first place. There are several jira issues about not deleting our chat logs and other files such as settings fles that could use some more looking at and perhaps some votes. VWR-21970 - https://jira.secondlife.com/browse/VWR-21970 VWR-17901 - https://jira.secondlife.com/browse/VWR-17901 VWR-17040 - https://jira.secondlife.com/browse/VWR-17040 STORM-280 - https://jira.secondlife.com/browse/STORM-280 PLAT-45 - https://jira.secondlife.com/browse/PLAT-45 VWR-17187 - https://jira.secondlife.com/browse/VWR-17187 VWR-20216 - https://jira.secondlife.com/browse/VWR-20216 VWR-18315 - https://jira.secondlife.com/browse/VWR-18315 There are probably some other related issues in addition to the above. On Thu, Oct 28, 2010 at 2:21 PM, Robert Martin wrote: > getting back to what i said > > 1 the uninstaller should state that it is removing the profile data > (best thing to do would be to zip it and put it in a folder on the > desktop) > > 2 TPVs should by default not use the default secondlife profile folder > (i would bet that 40% of SL/TPV problems could be solved by this > simple step) > > 3 the recycle bin is a gamble anyway and may not be safe to use (2 > gigs of profile data and a 1 gig recycle bin size = chunks of missing > data) > -- > Robert L Martin > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
I don't see this as a theoretical issue about whether the logs should be deleted, or not. (Note the word "should".) Many users don't like it. Don't do it. lee ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
Wow such a big discussion. I think the best plan would be to have both ways as an option like lots of installers do. Check this box to delete all files program created after it was installed simple enough and solves really any problem that arrises from left over cache and stuff if one is trying to reinstall a viewer On Thu, Oct 28, 2010 at 6:08 PM, Ponzu wrote: > I don't see this as a theoretical issue about whether the logs should be > deleted, or not. (Note the word "should".) > Many users don't like it. Don't do it. > lee > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Issue with Snowstorm build 213153
Hi, We had a strange issue today with that build which ended up being built from a merged node instead of the tip. The last 2 changeset in the tree are: changeset: 13218:f687381cc6bc tag: tip parent: 13216:f6305a7f525c parent: 13217:3795a42120f6 user:Merov Linden date:Wed Oct 27 11:44:33 2010 -0700 summary: STORM-452 : merge with viewer-development changeset: 13217:3795a42120f6 parent: 13205:f40486111006 user:Andrew Productengine date:Wed Oct 27 19:23:52 2010 +0300 summary: STORM-452 FIXED Made protective fix for crash in LLAgentCamera::resetView(). I pushed those (and other changes) at the same time on the tree. Clearly, "f687381cc6bc" is the tip but TC picked up "3795a42120f6" instead and that ended up building things that were missing a day of merges. A bunch of JIRA thus have been failing QA and were back in the "To Do" swim lane. We do not know why TC did this but it's possible this is a rare "back to the future" issue: the time stamp for Andrew changeset is actually more recent than the timestamp of my merge thanks to our respective time zones. We suspect that this confused TC when picking up the repo. After consulting with hg/TC experts, we think that this was a "one off" occurrence because of me merging aggressively Andrew's changes right after they were done. I'm going to resume merging now and, hopefully, everything will be back to normal in the next build. Thanks for your attention and sorry for the confusion. Cheers, - Merov ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
Just follow Microsoft requirements for Windows Logo for installation and uninstallation on the Windows platform. One of it is to never touch the user profile. This is a requirement for Terminal Services Aware applications. For removing "breadcrumbs", this is not working, an uninstaller cannot remove data from all user profiles, this is not possible. Instead an ISV can provide a profile cleanup utility. LL should follow the standards and restrictions. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin
6 years and 9 months of chat logs is not "bread crumbs". v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Issue with Snowstorm build 213153
Hi, As a follow up to this, it seems that build 213294 is all correct now: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/213294/index.html Cheers, - Merov On Thu, Oct 28, 2010 at 3:44 PM, Philippe (Merov) Bossut < me...@lindenlab.com> wrote: > Hi, > > We had a strange issue today with that build which ended up being built > from a merged node instead of the tip. The last 2 changeset in the tree are: > > changeset: 13218:f687381cc6bc > tag: tip > parent: 13216:f6305a7f525c > parent: 13217:3795a42120f6 > user:Merov Linden > date:Wed Oct 27 11:44:33 2010 -0700 > summary: STORM-452 : merge with viewer-development > > changeset: 13217:3795a42120f6 > parent: 13205:f40486111006 > user:Andrew Productengine > date:Wed Oct 27 19:23:52 2010 +0300 > summary: STORM-452 FIXED Made protective fix for crash in > LLAgentCamera::resetView(). > > I pushed those (and other changes) at the same time on the tree. Clearly, > "f687381cc6bc" is the tip but TC picked up "3795a42120f6" instead and that > ended up building things that were missing a day of merges. A bunch of JIRA > thus have been failing QA and were back in the "To Do" swim lane. > > We do not know why TC did this but it's possible this is a rare "back to > the future" issue: the time stamp for Andrew changeset is actually more > recent than the timestamp of my merge thanks to our respective time zones. > We suspect that this confused TC when picking up the repo. > > After consulting with hg/TC experts, we think that this was a "one off" > occurrence because of me merging aggressively Andrew's changes right after > they were done. I'm going to resume merging now and, hopefully, everything > will be back to normal in the next build. > > Thanks for your attention and sorry for the confusion. > > Cheers, > - Merov > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
