On Thu, 2003-09-11 at 19:05, Ean Schuessler wrote:
> I say it should build from scratch using all DFSG tools if it is going
> to go in main. That's just me.
I think that if software is to be in main, then besides being
buildable with tools from main - it should also not lack
functionality (when r
On Fri, Sep 12, 2003 at 12:47:18AM -0400, Grzegorz B. Prokopski wrote:
> On Thu, 2003-09-11 at 19:05, Ean Schuessler wrote:
> > I say it should build from scratch using all DFSG tools if it is going
> > to go in main. That's just me.
I agree completely. That is the definition of main, isn't it?
>
On Thu, 2003-09-11 at 19:05, Ean Schuessler wrote:
> I say it should build from scratch using all DFSG tools if it is going
> to go in main. That's just me.
I think that if software is to be in main, then besides being
buildable with tools from main - it should also not lack
functionality (when r
I don't think I agree. If you can't compile the package with Free tools
then putting it in main doesn't make sense. You can't rebuild the
package using Free Software. Jikes or something was seriously taken to
task for their use of a JavaCC generated grammer. The arguement was that
even though you c
I don't think I agree. If you can't compile the package with Free tools
then putting it in main doesn't make sense. You can't rebuild the
package using Free Software. Jikes or something was seriously taken to
task for their use of a JavaCC generated grammer. The arguement was that
even though you c
Hallo Michael,
* Michael R Head wrote:
>Since my .eclipse/user.links has /home/burner/.eclipse in it, I would
>expect to put plugins in /home/burner/.eclipse/plugins (or
>/usr/share/eclipse/plugins for the shared install)
This is unfortunatelly *not* right: Eclipse expects to find the dir
'eclips
Hallo David,
* David Goodenough wrote:
>I think I understand from the docs and bits I have found on the web that
>I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
>sure. I tried that and it did not seem to work.
Have a look in the /.metatdata/.config/platform.cfg file
an
Hallo Dalibor,
* Dalibor Topic wrote:
>I don't know how much of the VM options can be safely specified in such an
>interface. I guess the easiest way is to add a switch -Joption> that passes the option to the VM without specifying anything about the
>options the VM understands.
More or les it wil
On Thu, 2003-09-11 at 11:14, David Goodenough wrote:
>
> I think I understand from the docs and bits I have found on the web that
> I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
> sure. I tried that and it did not seem to work.
>
> Do I have to add anything to ~/.ecli
Hallo Michael,
* Michael R Head wrote:
>Since my .eclipse/user.links has /home/burner/.eclipse in it, I would
>expect to put plugins in /home/burner/.eclipse/plugins (or
>/usr/share/eclipse/plugins for the shared install)
This is unfortunatelly *not* right: Eclipse expects to find the dir
'eclips
I am running debian format eclipse on an unstable box, and I want to add a
plugin (the Swt-Designer plugin as it happens).
I think I understand from the docs and bits I have found on the web that
I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
sure. I tried that and it d
Hallo David,
* David Goodenough wrote:
>I think I understand from the docs and bits I have found on the web that
>I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
>sure. I tried that and it did not seem to work.
Have a look in the /.metatdata/.config/platform.cfg file
an
Hallo Dalibor,
* Dalibor Topic wrote:
>I don't know how much of the VM options can be safely specified in such an
>interface. I guess the easiest way is to add a switch -Joption> that passes the option to the VM without specifying anything about the
>options the VM understands.
More or les it wil
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> First of all, I will apologise for some of my heated 'answer round'
> during the last days. I still can't aggre completly with your (and
> others) objections, but I see that nothing won't change your opinion
> either :) so
On Thu, 2003-09-11 at 11:14, David Goodenough wrote:
>
> I think I understand from the docs and bits I have found on the web that
> I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
> sure. I tried that and it did not seem to work.
>
> Do I have to add anything to ~/.ecli
I am running debian format eclipse on an unstable box, and I want to add a
plugin (the Swt-Designer plugin as it happens).
I think I understand from the docs and bits I have found on the web that
I should put the plugin in ~/.eclipse/eclipse/plugins, but I am not quite
sure. I tried that and it d
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> First of all, I will apologise for some of my heated 'answer round'
> during the last days. I still can't aggre completly with your (and
> others) objections, but I see that nothing won't change your opinion
> either :) so
Hallo Dalibor,
* Dalibor Topic wrote:
>> Maybe the policy could say "A package must (should?) depend on the
>> disjunction of all JVMs with which it has been tested succesfully". That
>> does not force the packager to use any non-free program, but gives
>> strength to bug reports to include ano
Hallo Egon,
* Egon Willighagen wrote:
>On Thursday 11 September 2003 09:37, Mark Howard wrote:
>> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
>If they are in contrib or even non-free, then they do not violate any policy,
>so important maybe, but I would say just normal... and cer
Hallo Dalibor,
* Dalibor Topic wrote:
>> Maybe the policy could say "A package must (should?) depend on the
>> disjunction of all JVMs with which it has been tested succesfully". That
>> does not force the packager to use any non-free program, but gives
>> strength to bug reports to include ano
Hallo Egon,
* Egon Willighagen wrote:
>On Thursday 11 September 2003 09:37, Mark Howard wrote:
>> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
>If they are in contrib or even non-free, then they do not violate any policy,
>so important maybe, but I would say just normal... and cer
Konichiwa Takashi,
--- Takashi Okamoto <[EMAIL PROTECTED]> wrote:
> From: Dalibor Topic <[EMAIL PROTECTED]>
> Subject: Re: JAVA_HOME and ant
> Date: Tue, 9 Sep 2003 08:50:57 -0700 (PDT)
> > I think the code in question (javadoc task) is going to be rewritten to use
> a
> > delegation model soon an
Salut Daniel,
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> Isn't it fine if another person testifies that the package works with
> this-or-that JVM? I suppose this already happens with specific
> architectures or hardware.
> So if a package works with a JVM not in its depends, one can file a
--- Mark Howard <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> > I feel that despite whatever decisions we make about free and non-free
> > VMs and tools etc, we should firstly pay attention to simply compiling
> > our software with free tools and again
On Thursday 11 September 2003 09:37, Mark Howard wrote:
> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> > I feel that despite whatever decisions we make about free and non-free
> > VMs and tools etc, we should firstly pay attention to simply compiling
> > our software with free too
On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> I feel that despite whatever decisions we make about free and non-free
> VMs and tools etc, we should firstly pay attention to simply compiling
> our software with free tools and against free libraries or free APIs.
Doesn't this happen
Konichiwa Takashi,
--- Takashi Okamoto <[EMAIL PROTECTED]> wrote:
> From: Dalibor Topic <[EMAIL PROTECTED]>
> Subject: Re: JAVA_HOME and ant
> Date: Tue, 9 Sep 2003 08:50:57 -0700 (PDT)
> > I think the code in question (javadoc task) is going to be rewritten to use
> a
> > delegation model soon an
Salut Daniel,
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> Isn't it fine if another person testifies that the package works with
> this-or-that JVM? I suppose this already happens with specific
> architectures or hardware.
> So if a package works with a JVM not in its depends, one can file a
--- Mark Howard <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> > I feel that despite whatever decisions we make about free and non-free
> > VMs and tools etc, we should firstly pay attention to simply compiling
> > our software with free tools and again
On Thursday 11 September 2003 09:37, Mark Howard wrote:
> On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> > I feel that despite whatever decisions we make about free and non-free
> > VMs and tools etc, we should firstly pay attention to simply compiling
> > our software with free too
I will neither propose nor agree with a debian java policy, which will
ignore this facts and make out users patch debian packages to get this
working.
I don't see the point of making a policy that says that packages must
work with some non-packaged non-free programs. It would be nice if t
On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote:
> I feel that despite whatever decisions we make about free and non-free
> VMs and tools etc, we should firstly pay attention to simply compiling
> our software with free tools and against free libraries or free APIs.
Doesn't this happen
> What about an environment variable? Like
> $ someapp
> # runs someapp with one of the packagers tested JVM
> $ JAVA=/usr/bin/kaffe someapp
> # runs with kaffe
This works for me (and indeed it's what I've done with the jython
package).
> Is there is a risk of JAVA being already in use for some
A better way in my opinion is to allow the user to 'override' maintainer's
choice of VM environment in some easy way (like putting another java executable
in front of his path, or running a selectmyvm script).
I agree this is a good solution: the default behaviour is going to work
because the mai
34 matches
Mail list logo
