Hi Amanda,
I've checked out vuze source code through CVS from sourceforge and
edited in sun studio and then created the jar. Now I have the jar and I
want to copy my jar through the spec file. I specified it as SOURCE and
in %install section, I wrote like this....
install %{SOURCE3} $RPM_BUILD_ROOT%{_datadir}/Azureus
This is wrong i belive.
One issue here is, I need to replace the old Azureus2.jar which comes by
default through the sourceforge.net by my Azureus.jar. Where should I do
this ? Should it be done by just a cp command in %setup section ?
Thanks
Spoorthy
Amanda Waite wrote:
> Spoorthy H.S wrote:
>> 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 ?
>
> Are you building the azureus2.jar outside of the spec file? If you are
> then the best option is take all of the work you've done in building
> the jar and incorporate it into the vuze spec file. Then you just need
> to supply one or more patch files that contain the changes that you
> made to disable the update checker. In the spec file you then add an
> extra source URL and pull in the Azureus sources at build time. You
> can manage more than one source tarball with the -b n option to
> %setup. After that it's just a case of making sure that you are in the
> right directory when you do stuff.
>
> If it helps, I have an internal sandbox system that you could use to
> test as you work.
>
> Amanda
>
>>
>> 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
>>>
>
