Hello,
does anybody know what the deal is/plans are with the azureus package? It hasn't been updated for more than 7 months and it has been flagged out of date for a couple of months now too (as far as I remember). If the devs are not interested in maintaining it, shouldn't it be moved either to community or to unsupported where perhaps someone would pick it up and update the PKBGUILD?
Ondřej
2008/4/11 Ondřej Kučera ondrej.kucera@centrum.cz:
Hello,
does anybody know what the deal is/plans are with the azureus package? It hasn't been updated for more than 7 months and it has been flagged out of date for a couple of months now too (as far as I remember). If the devs are not interested in maintaining it, shouldn't it be moved either to community or to unsupported where perhaps someone would pick it up and update the PKBGUILD?
Interesting point. I checked up on it and it IS orphaned. I'll CC the dev list to see if anyone is interested in it. If not, then perhaps it would be best to move it to community.
On Fri, Apr 11, 2008 at 04:59:07PM -0500, Aaron Griffin wrote:
2008/4/11 Ondřej Kučera ondrej.kucera@centrum.cz:
Interesting point. I checked up on it and it IS orphaned. I'll CC the dev list to see if anyone is interested in it. If not, then perhaps it would be best to move it to community.
This might be a good time to bring this up. I don't know. It used to be my package, and easy to deal with at that. But at some point someone went through and added nine patches removing support for things like osx and other junk, so I figured they probably wanted to maintain it and orphaned it. Guess not.
Another change that was made was to make it compile from source... Now, Azureus is a java package, compiling it ourselves is of no benefit whatsoever since java uses a virtual machine.
I'm willing to update it again, but is it ok with everyone if I don't compile it from source, or is there something I'm missing?
-S
On Fri, 2008-04-11 at 20:24 -0500, Simo Leone wrote:
On Fri, Apr 11, 2008 at 04:59:07PM -0500, Aaron Griffin wrote:
2008/4/11 Ondřej Kučera ondrej.kucera@centrum.cz:
Interesting point. I checked up on it and it IS orphaned. I'll CC the dev list to see if anyone is interested in it. If not, then perhaps it would be best to move it to community.
This might be a good time to bring this up. I don't know. It used to be my package, and easy to deal with at that. But at some point someone went through and added nine patches removing support for things like osx and other junk, so I figured they probably wanted to maintain it and orphaned it. Guess not.
Another change that was made was to make it compile from source... Now, Azureus is a java package, compiling it ourselves is of no benefit whatsoever since java uses a virtual machine.
I'm willing to update it again, but is it ok with everyone if I don't compile it from source, or is there something I'm missing?
-S
I could update it again. The reason for patching it during froscon was that upstream azureus doesn't work with GNU java. Another thing was that the jarfile contains a lot of Windows and Mac OS X related things, the update manager doesn't work happily together with pacman packages and the upstream distribution contains either outdated copies of libraries where we have packages for, or just references to outdated copies that are incompatible with our installed versions.
I had a look at the source, I can reduce some patches, as most are not needed anymore. Back then, I wrote two patches to remove some com.sun.* usage, they don't apply anymore and I have to check if they're still needed and if so, rewrite them.
Another thing I stumbled on were the dependencies:
=dev-java/bcprov-1.35:0 =dev-java/commons-cli-1.0:1 =dev-java/log4j-1.2.8:0 =dev-java/swt-3.4_pre6-r1:3.4
That's what gentoo lists as dependencies (there's no clear reference of dependencies in the upstream source at all... just compile errors with weird missing references when you don't have these installed).
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
Hmm... How about putting swt 3.4m6 and azureus 3.0.5.0 into testing (so that those who want it could at their own risk download something based on a development version of a library)? It would mean creating packages for commons-cli and log4j though, I have no idea how hard would those be.
Ondřej
On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote:
I could update it again. The reason for patching it during froscon was that upstream azureus doesn't work with GNU java.
Why do we care? What's wrong with depending on Sun's java package?
Another thing was that the jarfile contains a lot of Windows and Mac OS X related things, the update manager doesn't work happily together with pacman packages and the upstream distribution contains either outdated copies of libraries where we have packages for, or just references to outdated copies that are incompatible with our installed versions.
Now some of that can be a problem.
I had a look at the source, I can reduce some patches, as most are not needed anymore. Back then, I wrote two patches to remove some com.sun.* usage, they don't apply anymore and I have to check if they're still needed and if so, rewrite them.
See first response.
Another thing I stumbled on were the dependencies:
=dev-java/bcprov-1.35:0 =dev-java/commons-cli-1.0:1 =dev-java/log4j-1.2.8:0 =dev-java/swt-3.4_pre6-r1:3.4
That's what gentoo lists as dependencies (there's no clear reference of dependencies in the upstream source at all... just compile errors with weird missing references when you don't have these installed).
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
Augh. Maybe we should go back to using the ones included with the jarfile, since I think the java policy we've got is basically... "split it if you can, don't bother if it's a hassle". This is starting to sound like a hassle to me.
-S
On Sun, 13 Apr 2008 02:12:41 -0500 Simo Leone simo@archlinux.org wrote:
On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote:
I could update it again. The reason for patching it during froscon was that upstream azureus doesn't work with GNU java.
Why do we care? What's wrong with depending on Sun's java package?
Another thing was that the jarfile contains a lot of Windows and Mac OS X related things, the update manager doesn't work happily together with pacman packages and the upstream distribution contains either outdated copies of libraries where we have packages for, or just references to outdated copies that are incompatible with our installed versions.
Now some of that can be a problem.
I had a look at the source, I can reduce some patches, as most are not needed anymore. Back then, I wrote two patches to remove some com.sun.* usage, they don't apply anymore and I have to check if they're still needed and if so, rewrite them.
See first response.
Another thing I stumbled on were the dependencies:
=dev-java/bcprov-1.35:0 =dev-java/commons-cli-1.0:1 =dev-java/log4j-1.2.8:0 =dev-java/swt-3.4_pre6-r1:3.4
That's what gentoo lists as dependencies (there's no clear reference of dependencies in the upstream source at all... just compile errors with weird missing references when you don't have these installed).
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
Augh. Maybe we should go back to using the ones included with the jarfile, since I think the java policy we've got is basically... "split it if you can, don't bother if it's a hassle". This is starting to sound like a hassle to me.
-S
I'll open this again... I think the main question now is - how many Archers are actually interested in Azureus? I mean if I'm the only one who uses it (or there's only a few of us), is there any reason for it to be in [extra] (where it is unmaintained anyway), shouldn't it be simple moved to unsupported (where someone would or wouldn't pick it up)? Is there any way to find out how popular a package in [extra] is (something like votes in AUR)?
Anyway I created a new package in AUR, vuze (which is the new name of Azureus, I didn't even know that) - http://aur.archlinux.org/packages.php?ID=17932. It simply downloads the latest binary version and puts it to /opt. It seems to work OK - at least it starts and is able to start downloading a torrent of ArchLinux's ISO. :-) The PKGBUILD is very basic for now, I just wanted to know if anyone is actually interested at all (if you are, please leave a comment and/or vote). It has the following limitations: (1) Right now, only x86_64 is supported, some juggling similar to what is done in PKGBUILD for Opera will be needed. (2) Depends on jre. Perhaps it would be more correct to depend on java-runtime but I don't have time to test it under java-gcj-compat. (3) Perhaps it should provide azureus and conflict with azureus. It doesn't have any conflicting files with the azureus package though. On the other hand, using both might mess with $HOME/.azureus...
Any comments? I really don't think that there should be a package in core/extra/community unmaintained for such a long time.
2008/6/20 Ondřej Kučera ondrej.kucera@centrum.cz:
On Sun, 13 Apr 2008 02:12:41 -0500 Simo Leone simo@archlinux.org wrote:
On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote:
I could update it again. The reason for patching it during froscon was that upstream azureus doesn't work with GNU java.
Why do we care? What's wrong with depending on Sun's java package?
Another thing was that the jarfile contains a lot of Windows and Mac OS X related things, the update manager doesn't work happily together with pacman packages and the upstream distribution contains either outdated copies of libraries where we have packages for, or just references to outdated copies that are incompatible with our installed versions.
Now some of that can be a problem.
I had a look at the source, I can reduce some patches, as most are not needed anymore. Back then, I wrote two patches to remove some com.sun.* usage, they don't apply anymore and I have to check if they're still needed and if so, rewrite them.
See first response.
Another thing I stumbled on were the dependencies:
=dev-java/bcprov-1.35:0 =dev-java/commons-cli-1.0:1 =dev-java/log4j-1.2.8:0 =dev-java/swt-3.4_pre6-r1:3.4
That's what gentoo lists as dependencies (there's no clear reference of dependencies in the upstream source at all... just compile errors with weird missing references when you don't have these installed).
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
Augh. Maybe we should go back to using the ones included with the jarfile, since I think the java policy we've got is basically... "split it if you can, don't bother if it's a hassle". This is starting to sound like a hassle to me.
-S
I'll open this again... I think the main question now is - how many Archers are actually interested in Azureus? I mean if I'm the only one who uses it (or there's only a few of us), is there any reason for it to be in [extra] (where it is unmaintained anyway), shouldn't it be simple moved to unsupported (where someone would or wouldn't pick it up)? Is there any way to find out how popular a package in [extra] is (something like votes in AUR)?
Anyway I created a new package in AUR, vuze (which is the new name of Azureus, I didn't even know that) - http://aur.archlinux.org/packages.php?ID=17932. It simply downloads the latest binary version and puts it to /opt. It seems to work OK - at least it starts and is able to start downloading a torrent of ArchLinux's ISO. :-) The PKGBUILD is very basic for now, I just wanted to know if anyone is actually interested at all (if you are, please leave a comment and/or vote). It has the following limitations: (1) Right now, only x86_64 is supported, some juggling similar to what is done in PKGBUILD for Opera will be needed. (2) Depends on jre. Perhaps it would be more correct to depend on java-runtime but I don't have time to test it under java-gcj-compat. (3) Perhaps it should provide azureus and conflict with azureus. It doesn't have any conflicting files with the azureus package though. On the other hand, using both might mess with $HOME/.azureus...
Any comments? I really don't think that there should be a package in core/extra/community unmaintained for such a long time.
-- Cheers, Ondřej Kučera
Personally, due to the home clash, I would suggest that it conflict. According to PKGBUILD man page, it should also use replace=, because there's been a change in upstream naming.
I'm hardly official, but it's been my experience that noone (In #archlinux) uses Azureus anyway, so I'd second a move out of extra.
On Fri, 20 Jun 2008, Daenyth Blank wrote:
2008/6/20 Ond?ej Ku?era ondrej.kucera@centrum.cz:
On Sun, 13 Apr 2008 02:12:41 -0500 Simo Leone simo@archlinux.org wrote:
On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote:
I could update it again. The reason for patching it during froscon was that upstream azureus doesn't work with GNU java.
Why do we care? What's wrong with depending on Sun's java package?
Another thing was that the jarfile contains a lot of Windows and Mac OS X related things, the update manager doesn't work happily together with pacman packages and the upstream distribution contains either outdated copies of libraries where we have packages for, or just references to outdated copies that are incompatible with our installed versions.
Now some of that can be a problem.
I had a look at the source, I can reduce some patches, as most are not needed anymore. Back then, I wrote two patches to remove some com.sun.* usage, they don't apply anymore and I have to check if they're still needed and if so, rewrite them.
See first response.
Another thing I stumbled on were the dependencies:
=dev-java/bcprov-1.35:0 =dev-java/commons-cli-1.0:1 =dev-java/log4j-1.2.8:0 =dev-java/swt-3.4_pre6-r1:3.4
That's what gentoo lists as dependencies (there's no clear reference of dependencies in the upstream source at all... just compile errors with weird missing references when you don't have these installed).
-bcprov is packaged -commons-cli isn't -neither is log4j -swt is at 3.3.x
Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to update swt to the development version, we're tied to the much older 3.0.4.2 release, which needs some additional patches to compile from source.
Augh. Maybe we should go back to using the ones included with the jarfile, since I think the java policy we've got is basically... "split it if you can, don't bother if it's a hassle". This is starting to sound like a hassle to me.
-S
I'll open this again... I think the main question now is - how many Archers are actually interested in Azureus? I mean if I'm the only one who uses it (or there's only a few of us), is there any reason for it to be in [extra] (where it is unmaintained anyway), shouldn't it be simple moved to unsupported (where someone would or wouldn't pick it up)? Is there any way to find out how popular a package in [extra] is (something like votes in AUR)?
Anyway I created a new package in AUR, vuze (which is the new name of Azureus, I didn't even know that) - http://aur.archlinux.org/packages.php?ID=17932. It simply downloads the latest binary version and puts it to /opt. It seems to work OK - at least it starts and is able to start downloading a torrent of ArchLinux's ISO. :-) The PKGBUILD is very basic for now, I just wanted to know if anyone is actually interested at all (if you are, please leave a comment and/or vote). It has the following limitations: (1) Right now, only x86_64 is supported, some juggling similar to what is done in PKGBUILD for Opera will be needed. (2) Depends on jre. Perhaps it would be more correct to depend on java-runtime but I don't have time to test it under java-gcj-compat. (3) Perhaps it should provide azureus and conflict with azureus. It doesn't have any conflicting files with the azureus package though. On the other hand, using both might mess with $HOME/.azureus...
Any comments? I really don't think that there should be a package in core/extra/community unmaintained for such a long time.
-- Cheers, Ond?ej Ku?era
Personally, due to the home clash, I would suggest that it conflict. According to PKGBUILD man page, it should also use replace=, because there's been a change in upstream naming.
I'm hardly official, but it's been my experience that noone (In #archlinux) uses Azureus anyway, so I'd second a move out of extra.
We are currently in the process of adding new devs. If none of them wants to maintain azureus, then it'll be moved to unsupported.
2008/6/21 Ondřej Kučera ondrej.kucera@centrum.cz:
Really loooooong text…
-- Cheers, Ondřej Kučera
I've used Azureus for a long time, but because of its age I've stopped using it and now I'm happy user of Ktorrent
participants (7)
-
Aaron Griffin
-
Daenyth Blank
-
Eric Belanger
-
Jan de Groot
-
Lukáš Jirkovský
-
Ondřej Kučera
-
Simo Leone