Spoorthy H.S wrote:
> Hi,
>
> * The CLASSPATH is set at only one place in the code which is
>
> /# build the classpath
> for FILE in ./*.jar; do
> CLASSPATH="${CLASSPATH:+${CLASSPATH}:}$FILE"
> done CLASSPATH=/usr/share/lib/java/swt.jar:$CLASSPATH /
>
> After the for loop, the classpath will be empty because it has
> searched in /usr/share/Azureus directory where swt.jar file wont be
> found.And I believe its taking the correct swt.jar from right
> location. I am not understanding why this is the problem. It will be
> helpful if anybody helps me to put the right classpath in that case.
When ever I've installed your vuze package the last line of what you've
listed above is always:
CLASSPATH=$CLASSPATH:/usr/lib/swt/swt.jar
and that line is added by your patch. Change the patch file to:
@@ -161,6 +162,8 @@
CLASSPATH="${CLASSPATH:+${CLASSPATH}:}$FILE"
done
+CLASSPATH=$CLASSPATH:/usr/share/lib/java/swt.jar
+
# setup Java System Properties (no spaces in values)
JAVA_PROPS="-Dazureus.script.version=${SCRIPT_VERSION}"
if [ ! "$JAVA_ISGCJ x" = " x" ] ; then
Amanda
>
> * I have the newer version of SUNWswt package I had built which is not
> ported yet.[The newer version of swt is 3.4.2].And I'm unsure whether
> it resolves the problem.
>
> * As suggested by Andras and others, I can try to disable the update
> check entirely. This can be done by just starting the client with
> classic UI. /[ with -Dforce.ui=az2 before setting
> -Djava.library.path]. /I am trying for other kind of solutions also
> for this.
> Thanks
> Spoorthy
>
> George Drapeau wrote:
>>
>>
>> Bruce Rothermal wrote:
>>> So before you vote this down. How long will it take to get this bug
>>> fixed. This package (vuze) is not being ported because it is an
>>> interesting piece of software. It is a required mandatory package
>>> needed for a project in the HPC Deployer project.
>> Ahh, interesting. Well to me, that raises the bar on the quality
>> standards of this package before it goes out. Seems like the
>> following problems should get taken care of, then, if it's not just a
>> fun app:
>>
>> 1) Fix the classpath problem in the package submission to correctly
>> point to the installed location of SWT.
>>
>> 2) The SUNWswt package itself should be fixed to include browser
>> support and OpenSolaris support in general. Spoorthy, you mention a
>> more recent version of SWT. Do you know if that version remedies the
>> problems Amanda and I experience before? And if so, do you know when
>> the updated version will be part of OpenSolaris?
>>
>> 3) (related to #2) Either specify a dependency on Thunderbird
>> (because that's where XULrunner is now) or enhance the Firefox
>> package so that it distributes XULrunner componentry, upon which SWT
>> depends for HTML rendering, upon which Vuze depends for correct and
>> complete operation.
>>
>> 4) The dependencies issue in SourceJuicer.
>>
>> By the way: to make SWT complain less, I had to change an option in
>> the Vuze startup script telling it where to find the XULrunner
>> component in Thunderbird. Depending on how items #2 and #3 above get
>> resolved, this startup script may or may not need to be modified to
>> match.
>>
>> George
>>>
>>> Bruce
>>>
>>>
>>> On May 13, 2009, at 8:41 AM, George Drapeau wrote:
>>>
>>>>
>>>>
>>>> Eric Reid - Sun ISV Engineering wrote:
>>>>> <snip>
>>>>>>
>>>>>>>
>>>>>>> - the app's BitTorrent upload and download capabilities worked
>>>>>>> fine; it's good enough to use as a BitTorrent client, but will
>>>>>>> be missing some functionality (no rendering of the Vuze HD
>>>>>>> Network page since no HTML browser support since it's not in SWT
>>>>>>> on OpenSolaris as far as I could tell).
>>>>>> If main functionality is there but satelite functionality isnt
>>>>>> working, it's good enough for /contrib. But not for other repos.
>>>>> Gosh, I have a HUGE problem with this. IPS packages enforce
>>>>> dependencies at install time, as do all mature packaging systems
>>>>> today. The fact that SJ has a bug, IMHO, is *not* reason enough to
>>>>> claim these IPS packages in /contrib are "good enough". All the
>>>>> caveats in the world will not head off potential installation
>>>>> experience headaches, which will then turn people off from
>>>>> OpenSolaris.
>>>> You've changed my mind; rather, I should have been more specific in
>>>> my last message about my opinion on the Vuze / Azureus package. I
>>>> would call Vuze an alpha or beta level release because it works but
>>>> lacks known functionality; I can live with that, if the package
>>>> submitter were to rapidly improve the package. But this whole
>>>> lack-of-dependency-checking thing is a show-stopper for packages
>>>> submitted via Juicer. I apologize; I completely ignored that in my
>>>> most recent message, even though I mentioned it my early comments
>>>> on the package.
>>>>
>>>> Dependencies not working: sounds like a no-go to me for any package
>>>> submission that specifies package dependencies. Seems like that
>>>> should get fixed, then every package submitted that specified
>>>> dependencies can be re-checked easily, then they can all go
>>>> through. But they shouldn't go through now.
>>>>
>>>> Separately, Amanda made a good point about the other Vuze package
>>>> bug, not correctly specifying the path to swt.jar. That does need
>>>> to be fixed before this package is ready to be released.
>>>>>
>>>>> I could not in good conscience give a +1 to such packages.
>>>>>
>>>>> I would be curious to hear the opinions of the other SW-Porters
>>>>> Core Contributors.
>>>>>
>>>> Me, too. I think it's straightforward enough: why allow packages
>>>> to be released when we know they're missing the dependency stuff?
>>>> The bug will get fixed at some point, then we'll just have more
>>>> packages ready to be published, but not until then. Do the other
>>>> Core Contributors agree?
>>>>
>>>> G.
>>>>
>>>> _______________________________________________
>>>> sw-porters-discuss mailing list
>>>> sw-porters-discuss at opensolaris.org
>>>> <mailto:sw-porters-discuss at opensolaris.org>
>>>> http://mail.opensolaris.org/mailman/listinfo/sw-porters-discuss
>>>
>>
>> --
>> <http://www.sun.com> * George Drapeau *
>> Open Source Lead, ISV Engineering
>> *Sun Microsystems, Inc.*
>> 16 Network Circle, M/S UMPK16-314
>> Menlo Park, CA 94025 US
>> Phone/Fax +1 650 786 1789
>> AIM: gdeweydrapeau; Yahoo!: georgedrapeau
>> *George.Drapeau at Sun.COM <mailto:George.Drapeau at Sun.COM>*
>> http://blogs.sun.com/drapeau
>>
