Hi George,
I have found one more solution to disable the update checker entirely.
It is to modify the source code to disable that option by default, and
compile our own version of azureus2.jar. The problem exists here is ...
I'm downloading the tar file in spec file directly from
http://easynews.dl.sourceforge.net/azureus/Vuze_4.1.0.4_linux-x86_64.tar.bz2
and untarred components will get stored at /usr/share/Azureus by
default. How can I do this when I am downloading Vuze source from vuze
website directly ?
Thanks
Spoorthy
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.
>
> * 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
>>
> _______________________________________________
> sw-porters-discuss mailing list
> sw-porters-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/sw-porters-discuss
