Hi George, I am able to create my own Azureus2.jar by editing the code for /*disabling the update checker*. /Unlike the solution you gave, I edited the part of code [line 229 of http://fisheye1.atlassian.com/browse/azureus/azureus2/org/gudy/azureus2/core3/config/impl/ConfigurationDefaults.java?r=1.322] which was identified by one of the active vuze forum member. Now, I am struck. I want to know how to embed this jar into the package ? I just need to do a "cp-means copy" [which replaces old Azureus2.jar] of my jar into the Azureus ? I need help on this. Do I need to do this stuff in %setup section ?
Thanks Spoorthy George Drapeau wrote: > 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> >>>>>> <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 >>> <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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/sw-porters-discuss/attachments/20090526/bffa1a2f/attachment.html>
