All, Having received the required +1 and all issues resolved I am closing this fast track as approved.
Thanks, John Margot Miller wrote: > +1 > > Thanks > Margot > > > John Fischer wrote: >> All, >> >> With all the issues having been answered I am still waiting a +1. >> >> Thanks, >> >> John >> >> >> abhijit wrote: >>> Brian, >>> John is perfectly correct. We really don't have any problem if >>> GStreamer use gnome private libraries. >>> At this moment, it is difficult to make the new gnome libraries as >>> public. >>> >>> Abhijit >>> >>> John Fischer wrote: >>>> Brian, >>>> >>>> In talking with Parthasarathi and Abhijit they understand the desire by >>>> Java to have GStreamer in Solaris 10. However, they do not want to end >>>> up pulling in a bunch of support issues by making them a public >>>> interface. With that said I am sure that they would be willing to sign >>>> a contract when Java comes to the committee to us the interface. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> Brian Cameron wrote: >>>>> >>>>> Margot: >>>>> >>>>>> What was the resolution to Brian Cameron's GSteamer needing GLib >>>>>> 2.12 or newer? It looks like this project is integrating version >>>>>> 2.14.4. Can GStreamer use that? If so, should the interface >>>>>> stability >>>>>> be consolidation private? Or, has it been determined that all these >>>>>> libraries are truly private? >>>>> >>>>> Just to reiterate what I said in the meeting. >>>>> >>>>> GLib 2.14.4 (or any version 2.12 or later) would be fine for >>>>> backporting GStreamer 0.10 to Solaris 10. >>>>> >>>>> It still is not clear if backporting GStreamer 0.10 is something that >>>>> will be done, but if the decision is made to do so, then it would >>>>> obviously make things easier if this GLib 2.14.4 library could be >>>>> used. >>>>> >>>>> It would be good to clarify what the interface stability level of >>>>> these >>>>> GNOME base libraries will be. If they are private, will it be >>>>> possible >>>>> to get a contract to use them for GStreamer 0.10 if needed? >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -------------------------------+------------------+---------------------------------+ >>>>>> >>>>>> >>>>>> |/usr/lib/gnome-private/glib-2.0 | Project private | Project >>>>>> private glib libraries | >>>>>> |/usr/lib/gnome-private/libglib*.so| | version >>>>>> 2.14.4 Thanks >>>>>> Margot >>>>>> >>>>>> >>>>>> On 05/13/09 10:00, John Fischer wrote: >>>>>>> All, >>>>>>> >>>>>>> Actually, I have set the timer for Friday, May 15th, 2009, COB PST. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> >>>>>>> John Fischer wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> Attached please find the updated proposal. I have reset the >>>>>>>> timer for >>>>>>>> Wednesday May 20th, 2009. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> John Fischer wrote: >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I am putting this case into need spec status to allow the >>>>>>>>> project team >>>>>>>>> to produce a new specification that addresses the sharing of >>>>>>>>> the Gnome >>>>>>>>> libraries and installation locations. Once this is done I will >>>>>>>>> restart >>>>>>>>> the timer appropriately. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> Abhijit Nath wrote: >>>>>>>>>> Alan/John, >>>>>>>>>> Yes, it is a mistake. We'll shift all the private libraries/ >>>>>>>>>> Firefox 3.0.x libraries in "/opt/firefox3". >>>>>>>>>> You are also correct about the LD_LIBRARY_PATH. We'll modify >>>>>>>>>> the one pager and incorporate LD_LIBRARY_PATH_32 and >>>>>>>>>> LD_LIBRARY_PATH_64. >>>>>>>>>> >>>>>>>>>> Some other frameworks' up-prive (eg GStreamer) also need >>>>>>>>>> upgraded gnome libraries( Refer Brian's mail). So we are in a >>>>>>>>>> process to check the feasibility of keeping all the upgraded >>>>>>>>>> libraires in a common place. We'll revert back asap. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Abhijit >>>>>>>>>> >>>>>>>>>> On 04/22/09 04:40, John Fischer wrote: >>>>>>>>>>> Alan, >>>>>>>>>>> >>>>>>>>>>> I totally missed the /opt/firefox and /opt/sfw issue. Thanks >>>>>>>>>>> for >>>>>>>>>>> catching that one. >>>>>>>>>>> >>>>>>>>>>> I'll let the project team address these issues. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Alan Coopersmith wrote: >>>>>>>>>>>> John Fischer wrote: >>>>>>>>>>>>> This project proposes to back port Firefox 3.0.x from >>>>>>>>>>>>> Nevada to a >>>>>>>>>>>>> Solaris 10 Update release which is a Patch release of >>>>>>>>>>>>> Solaris. >>>>>>>>>>>> >>>>>>>>>>>> Is it integrating into the update release or shipping as a >>>>>>>>>>>> separate >>>>>>>>>>>> web download running on top of the update release? (/opt >>>>>>>>>>>> would be >>>>>>>>>>>> wrong for the integrated case, right for the unbundled case). >>>>>>>>>>>> >>>>>>>>>>>> Is this intended to replace or supplement Firefox 2.x? >>>>>>>>>>>> >>>>>>>>>>>> The one-pager references both /opt/firefox3 & >>>>>>>>>>>> /opt/sfw/lib/firefox/ - can >>>>>>>>>>>> we assume /opt/firefox3 is correct since /opt/sfw is >>>>>>>>>>>> reserved for the >>>>>>>>>>>> Solaris Companion CD? >>>>>>>>>>>> >>>>>>>>>>>>> All the plugins are spawned by firefox-bin. So, >>>>>>>>>>>>> LD_LIBRARY_PATH >>>>>>>>>>>>> environment variable will be set to /opt/sfw/lib in >>>>>>>>>>>>> run-mozilla.sh >>>>>>>>>>>> >>>>>>>>>>>> This also seems incorrect - should this refer to the >>>>>>>>>>>> /opt/firefox3/lib >>>>>>>>>>>> directory or are you importing/depending on libraries from >>>>>>>>>>>> the Companion CD? >>>>>>>>>>>> >>>>>>>>>>>> (Also, in the unavoidable cases in which you must use >>>>>>>>>>>> LD_LIBRARY_PATH-type >>>>>>>>>>>> variables, you should always use LD_LIBRARY_PATH_32 or >>>>>>>>>>>> LD_LIBRARY_PATH_64 >>>>>>>>>>>> to avoid breaking programs of the other wordsize.) >>>>>>>>>>>> >>>>>>>>>>>> Are the library upgrades incompatible? Is there no way >>>>>>>>>>>> they can be >>>>>>>>>>>> shipped as updates to the existing public libraries in >>>>>>>>>>>> /usr/lib ? >>>>>>>>>>>> >>>>>>>>>>>> For the brand new libraries, like cairo & dbus, is there any >>>>>>>>>>>> architectural >>>>>>>>>>>> reason they must be private, or is this just a resource >>>>>>>>>>>> issue around supporting >>>>>>>>>>>> them? >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> opensolaris-arc mailing list >>>>>>>>> opensolaris-arc at opensolaris.org >>>>>>> _______________________________________________ >>>>>>> opensolaris-arc mailing list >>>>>>> opensolaris-arc at opensolaris.org >>>>>> >>>>>> _______________________________________________ >>>>>> opensolaris-arc mailing list >>>>>> opensolaris-arc at opensolaris.org >>>>> >>> >
