Hi Spoorthy,
Cool that you're making the Vuze package better; this will be nice when
you're done.
I looked around for how other platforms handled the problem of disabling
Vuze's auto-update feature. The best solution I found, unfortunately,
was to modify code (a better solution in my opinion would be for the
Vuze authors to add a startup option to disable auto-update).
Here's the bug with suggested solution near the bottom of the page:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405997
(look at Message #90 about 3/4 down the page; you'll see the removal of
registration for two classes, CoreUpdateChecker and CorePatchChecker)
Sounds like you've gotten help on the next issue, which is "Okay, I've
made code changes but haven't checked them into the trunk of the vuze
tree; how do I incorporate those changes into the Juicer?"
Thanks for doing this, and hope this helps,
G.
Spoorthy H.S wrote:
> 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
--
<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*
http://blogs.sun.com/drapeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/sw-porters-discuss/attachments/20090515/46ea59f7/attachment.html>
