package azureus
tag 405997 patch
thanks
Thanks for the patch, Arron! I'm still unsure if I want to disable the
auto-update feature. I've found it useful on systems that don't
receive automatic updates other than security updates. If the
auto-update plugin is disabled in this way, is it possible t
x-type OSes are exhibiting large icons in
the torrent lists)
Of course, patches to Azureus are also welcome :)
-ArronM/TuxPaper
Azureus Team wrote:
> -- Forwarded message --
> From: Shaun Jackman <[EMAIL PROTECTED]>
> Date: Jan 16, 2007 9:34 AM
> Subject: Re: Bug#405997
Shaun Jackman writes ("Re: Bug#405997: should executables be permitted to
update themselves?"):
> It is only possible for the user to download the upstream jar and run
> 'java azureus.jar' at the command line if he or she is technically
> capable of it. Presenting
On 1/15/07, Michael Gilbert <[EMAIL PROTECTED]> wrote:
...
the user did not initiate the action. azureus went out and checked for
updates, then told the user that they should update. and it does this every
time the application starts up unless the user chooses to update (at that
point, i don't
On 1/15/07, Jamin W. Collins <[EMAIL PROTECTED]> wrote:
...
After relaunching for the update the following error (not present prior
to the update appeared):
Error
SWT library loaded from "/usr/share/java" can't be automatically updated
from version 3235 to 3318 (must be loaded from
"/home/jcolli
On 1/14/07, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
...
If azereus is going out and adding things to the users home
dir without the users knowledge, that would be one thing. But in this
case the users has initiated the action -- and trying to save the
user from themselves is not on
> Ian Jackson wrote:
>> I don't know what azareus's UI for this is like but depending on the
>> situation it might be best to make a configuration option, set by
>> default, which suppresses it. For example, if the current
>> code presents dialogues nagging to be allowed to update from upstream,
Ian Jackson wrote:
>
> I don't know what azareus's UI for this is like but depending on the
> situation it might be best to make a configuration option, set by
> default, which suppresses it. For example, if the current
> code presents dialogues nagging to be allowed to update from upstream,
> th
On Sun, 14 Jan 2007 19:51:22 -, Michael Gilbert <[EMAIL PROTECTED]> said:
> On Jan 14, 1:10 pm, "Shaun Jackman" wrote:
>> On a stable Debian system, system-wide upgrades can be far
>> between. I prefer to give the user a choice of whether to use the
>> update system provided by the upstream a
On Sun, 14 Jan 2007 23:25:23 +, Neil McGovern <[EMAIL PROTECTED]> said:
> I'm not sure we'll be able to provide good security support if other
> random things are downloaded.
Users can always download random things. They can download
sources and compile them. They can install third
On Jan 14, 1:10 pm, "Shaun Jackman" wrote:
> On a stable Debian system, system-wide upgrades can be far between. I
> prefer to give the user a choice of whether to use the update system
> provided by the upstream author to update the software before the next
> stable release of Debian.
like i said
Shaun Jackman wrote:
On 1/14/07, Linas Žvirblis <[EMAIL PROTECTED]> wrote:
6. The upstream build may not be DFSG free.
Absolutely not our concern. It is the user's choice as to which
software she wishes to download and run.
And if the user selected Debian for its software guidelines? Don'
On 1/14/07, Sam Morris <[EMAIL PROTECTED]> wrote:
How does the azureus package work around the fact that only root can write
to the package files?
The updated software is stored in ~/.Azureus/.
BTW, if you and the maintainer cannot agree on this you can reassign the
bug to tech-ctte, but that
On 1/14/07, Linas Žvirblis <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Gilbert wrote:
> is there a policy on whether an executable is permitted to update
> itself?
Not sure about The Policy, but I can see a lot of reasons why this
should not be done:
1. T
[This mail was also posted to gmane.linux.debian.devel.policy.]
On Sun, 14 Jan 2007 00:26:15 -0500, Michael Gilbert wrote:
> is there a policy on whether an executable is permitted to update itself? i
> personally believe that in order to maintain the security of the system, apt
> and apt alone s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Gilbert wrote:
> is there a policy on whether an executable is permitted to update
> itself?
Not sure about The Policy, but I can see a lot of reasons why this
should not be done:
1. The md5 sums will not match anymore, so one cannot
ve
hello,
is there a policy on whether an executable is permitted to update itself? i
personally believe that in order to maintain the security of the system, apt
and apt alone should be used to install software updates. recently i
submitted a bug on azureus about how it should not urge users to i
17 matches
Mail list logo
