> You mean something like
>
> |You must depend on all working java virtual maschines and search all
> |this packages for the java virtual maschine binary.
Yes.
> I thought that this was fairly obvious... I mean, it's pretty stupit
> if not :)
There are lots of things in debian policy that are
> Searching /lib and /usr/lib is what gcj does by default. Should this be
> disabled to comply with the policy?
Policy only requires that /usr/lib/jni be added to the search path.
Whatever else you put there (e.g., /usr/lib, etc. for compatibility with
other distributions) is up to you.
Ben. :)
> >> 2.2. Java Development Tools
> [..]
> >Ant is used by some packages, but why mandate that ant must be used?
>
> Is now changed to 'If package uses ant, then it must... \n If not, ...'
FWIW, this "should use ant" directive occurs in two places. Once in
section 2.7 (which you said earlier tha
> I haven't used JNI much, so it would be nice if someone who packages a JNI
> library could chip in here and provide some insight about what's necesary, and
> how they use to find it.
For libreadline-java:
It builds explicitly against gcj and gcjh with the /usr/include/jni.h
provided by libgcj4
> >>From debian I'd expect a policy that helps and guides java
> >>apps/libs/jvm
> >maintainers to build and package their stuff with a focus on free
> >VMs, gives pointers who to get in topuch with if things don't work,
> >has a section on free java developers working on providing a free
> >java
> You mean something like
>
> |You must depend on all working java virtual maschines and search all
> |this packages for the java virtual maschine binary.
Yes.
> I thought that this was fairly obvious... I mean, it's pretty stupit
> if not :)
There are lots of things in debian policy that are
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> The problem in debian is to find out this java.
> This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class l
> Searching /lib and /usr/lib is what gcj does by default. Should this be
> disabled to comply with the policy?
Policy only requires that /usr/lib/jni be added to the search path.
Whatever else you put there (e.g., /usr/lib, etc. for compatibility with
other distributions) is up to you.
Ben. :)
> >> 2.2. Java Development Tools
> [..]
> >Ant is used by some packages, but why mandate that ant must be used?
>
> Is now changed to 'If package uses ant, then it must... \n If not, ...'
FWIW, this "should use ant" directive occurs in two places. Once in
section 2.7 (which you said earlier tha
> I haven't used JNI much, so it would be nice if someone who packages a JNI
> library could chip in here and provide some insight about what's necesary, and
> how they use to find it.
For libreadline-java:
It builds explicitly against gcj and gcjh with the /usr/include/jni.h
provided by libgcj4
> >>From debian I'd expect a policy that helps and guides java
> >>apps/libs/jvm
> >maintainers to build and package their stuff with a focus on free
> >VMs, gives pointers who to get in topuch with if things don't work,
> >has a section on free java developers working on providing a free
> >java
Hallo Dalibor,
* Dalibor Topic wrote:
>I haven't used JNI much, so it would be nice if someone who packages a JNI
>library could chip in here and provide some insight about what's necesary, and
>how they use to find it.
Same as usuall in the builds: get a JAVA_HOME and pass $JAVA_HOME/includes an
Hallo Dalibor,
* Dalibor Topic wrote:
>> I wanted to say, that you have a interface for the 'unfree' ones and
>> this interface will work, even if you have 'not working' JVM
>> installed. The current interface (/usr/bin/java) does not garantee,
>> that your package is working.
>I don't think that
Hallo Dalibor,
* Dalibor Topic wrote:
>> Currently you forbit this, as you only know where the BD package put
>> their java and so it will break if you have sun-java packaged
>> (mpkg-j2sdk) and instaleld with that name.
>Can't the maintainers of Blackdown Java and mpkg-j2sdk resolve this naming
>
Hallo Dalibor,
* Dalibor Topic wrote:
[rant about JAVA_HOME]
>I don't think that's a good foundation to build a policy on ;)
Is the current proposal better?
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
Hallo Dalibor,
* Dalibor Topic wrote:
>Why do you assume familiarity with some command line synopsis? The effect of
>-classpath a.jar:b.jar for example can have different effects depending on the
>VM used, and its version. That's what the documentation is good for ;)
>From my limited java experie
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
>> * Mark Wielaard wrote:
>> This would mean, that the resulting package will not use 'java' to
>> start the programm and it would be a normal ELF binary, for which all
>> teh rules from the debian policy apply.
>'
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> The problem in debian is to find out this java.
> This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class l
Hallo Mark,
* Mark Wielaard wrote:
>Try gij-3.3:
Don't have that just now... Yes, unstable is calling, even starting to
scream...
>> All compilers I know should be satisfied by that.
>OK. I am not a big Ant user. gcj needs a -C option to compile to byte
>code though. Or a --main and -o option
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ean,
>
> * Ean Schuessler wrote:
> >The problem is that "java2-runtime-" doesn't really
> >provide anything more than "j2re1.4". It is just a wordier way to refer
> >to Sun and IBM's VM, neither of which can actually be distributed by
Hallo Dalibor,
* Dalibor Topic wrote:
>I haven't used JNI much, so it would be nice if someone who packages a JNI
>library could chip in here and provide some insight about what's necesary, and
>how they use to find it.
Same as usuall in the builds: get a JAVA_HOME and pass $JAVA_HOME/includes an
Hallo Dalibor,
* Dalibor Topic wrote:
>> I wanted to say, that you have a interface for the 'unfree' ones and
>> this interface will work, even if you have 'not working' JVM
>> installed. The current interface (/usr/bin/java) does not garantee,
>> that your package is working.
>I don't think that
Hallo Dalibor,
* Dalibor Topic wrote:
>> Currently you forbit this, as you only know where the BD package put
>> their java and so it will break if you have sun-java packaged
>> (mpkg-j2sdk) and instaleld with that name.
>Can't the maintainers of Blackdown Java and mpkg-j2sdk resolve this naming
>
Hallo Dalibor,
* Dalibor Topic wrote:
[rant about JAVA_HOME]
>I don't think that's a good foundation to build a policy on ;)
Is the current proposal better?
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Hallo Dalibor,
* Dalibor Topic wrote:
>Why do you assume familiarity with some command line synopsis? The effect of
>-classpath a.jar:b.jar for example can have different effects depending on the
>VM used, and its version. That's what the documentation is good for ;)
>From my limited java experie
Hi Matt,
--- Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
>
> > > I used to be very busy/without net during last months but I am back.
> > > And attacking ;-)
> > >
> > > The problem is that currently jikes (in the sense of source pac
Hi,
On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >I am one of the GNU Classpath developers but not a Debian developer.
>
> Thanks for joining anyway :)
I am a Debian user though and use it for all my development machines.
> >For end-user programs I think it would be
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> I wanted to say, that you have a interface for the 'unfree' ones and
> this interface will work, even if you have 'not working' JVM
> installed. The current interface (/usr/bin/java) does not garan
On Sat, 2003-09-06 at 14:32, Matt Zimmerman wrote:
> What you are missing is that Debian binary packages must stay in sync with
> their source package, which means that all of the packages that jikes builds
> are handled as a group for release purposes.
>
> If this is causing a problem, the obviou
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should
> be
> >in there, or how it should work. It's just a part of the ugly java folklore,
> >like trigraphs in C. ;)
>
> Bu
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
>> * Mark Wielaard wrote:
>> This would mean, that the resulting package will not use 'java' to
>> start the programm and it would be a normal ELF binary, for which all
>> teh rules from the debian policy apply.
>'
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >If the packages need java, the executable, they should use whatever 'java'
> is
> >in the PATH. If they need it to load
> >sun.only.dedicated.morons.use.this.api.Main, then they are broken and need
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >And finally, what's the effect of -classpath a.jar:b.jar supposed to
> >be? How does it alter the class lookup? What about the current
> >directory? Is that included automatically? And so on ...
>
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
> > I used to be very busy/without net during last months but I am back.
> > And attacking ;-)
> >
> > The problem is that currently jikes (in the sense of source package,
> > which is important from testing migration scripts POV) dep
--- "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> wrote:
> Package: jikes
> Version: 1.18-6
> Severity: wishlist
>
> Hi all!
>
> I used to be very busy/without net during last months but I am back.
> And attacking ;-)
>
> The problem is that currently jikes (in the sense of source package,
> whic
Hi,
On Sat, 2003-09-06 at 17:29, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >gij does come with a normal long-option --classpath. But as the gij help
> >output says: "Options can be specified with `-' or `--'."
>
> --8<-:- snip -:-8<-:- snip -:-8<--
> [EMAIL PROT
Hallo Mark,
* Mark Wielaard wrote:
>I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
>For end-user programs I think it would be a good idea to mention that
>gcj can be used to compile programs written in the java language into
>normal native binar
Hallo Ben,
* Ben Burton wrote:
>> Java libraries must depend on the needed working runtime
>> environments, including the virtual package names of working
>> versions of the "unfree" bin/java interface.
>If you're going to mandate that developers keep a list of working JVMs
>for their dependencies
Hallo Mark,
* Mark Wielaard wrote:
>Try gij-3.3:
Don't have that just now... Yes, unstable is calling, even starting to
scream...
>> All compilers I know should be satisfied by that.
>OK. I am not a big Ant user. gcj needs a -C option to compile to byte
>code though. Or a --main and -o option
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ean,
>
> * Ean Schuessler wrote:
> >The problem is that "java2-runtime-" doesn't really
> >provide anything more than "j2re1.4". It is just a wordier way to refer
> >to Sun and IBM's VM, neither of which can actually be distributed by
Hi Matt,
--- Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
>
> > > I used to be very busy/without net during last months but I am back.
> > > And attacking ;-)
> > >
> > > The problem is that currently jikes (in the sense of source pac
Hi,
On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >I am one of the GNU Classpath developers but not a Debian developer.
>
> Thanks for joining anyway :)
I am a Debian user though and use it for all my development machines.
> >For end-user programs I think it would be
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> I wanted to say, that you have a interface for the 'unfree' ones and
> this interface will work, even if you have 'not working' JVM
> installed. The current interface (/usr/bin/java) does not garan
On Sat, 2003-09-06 at 14:32, Matt Zimmerman wrote:
> What you are missing is that Debian binary packages must stay in sync with
> their source package, which means that all of the packages that jikes builds
> are handled as a group for release purposes.
>
> If this is causing a problem, the obviou
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should
> be
> >in there, or how it should work. It's just a part of the ugly java folklore,
> >like trigraphs in C. ;)
>
> Bu
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >If the packages need java, the executable, they should use whatever 'java'
> is
> >in the PATH. If they need it to load
> >sun.only.dedicated.morons.use.this.api.Main, then they are broken and need
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >And finally, what's the effect of -classpath a.jar:b.jar supposed to
> >be? How does it alter the class lookup? What about the current
> >directory? Is that included automatically? And so on ...
>
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
> > I used to be very busy/without net during last months but I am back.
> > And attacking ;-)
> >
> > The problem is that currently jikes (in the sense of source package,
> > which is important from testing migration scripts POV) dep
Hallo Mark,
* Mark Wielaard wrote:
>gij does come with a normal long-option --classpath. But as the gij help
>output says: "Options can be specified with `-' or `--'."
--8<-:- snip -:-8<-:- snip -:-8<--
[EMAIL PROTECTED]:/$ gij-3.0 --help
Usage: gij [OPTION] ... CL
--- "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> wrote:
> Package: jikes
> Version: 1.18-6
> Severity: wishlist
>
> Hi all!
>
> I used to be very busy/without net during last months but I am back.
> And attacking ;-)
>
> The problem is that currently jikes (in the sense of source package,
> whic
Hi,
On Sat, 2003-09-06 at 17:29, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >gij does come with a normal long-option --classpath. But as the gij help
> >output says: "Options can be specified with `-' or `--'."
>
> --8<-:- snip -:-8<-:- snip -:-8<--
> [EMAIL PROT
Hallo Mark,
* Mark Wielaard wrote:
>I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
>For end-user programs I think it would be a good idea to mention that
>gcj can be used to compile programs written in the java language into
>normal native binar
Hallo Ben,
* Ben Burton wrote:
>> Java libraries must depend on the needed working runtime
>> environments, including the virtual package names of working
>> versions of the "unfree" bin/java interface.
>If you're going to mandate that developers keep a list of working JVMs
>for their dependencies
> Are there any other requirements? Should /lib and /usr/lib be searched
> or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
"normal" application libraries).
In particular, java policy also
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
> Chapter 2. Policy
>
> Packages written in Java are separated in two categories: programs
> and libraries. Programs are intended to be run by end-users.
> Libraries are intend
> If the discussed proposal is used, this will be the only way to do it.
>
> -> A 'ant environment', which will use jikes as a compiler, will set
> the ANT_BUILD_COMPILER to jikes and ant will use jikes as a compiler.
What if I don't want to use ant?
The current jikes-* wrappers let me drop in
Hallo Mark,
* Mark Wielaard wrote:
>gij does come with a normal long-option --classpath. But as the gij help
>output says: "Options can be specified with `-' or `--'."
--8<-:- snip -:-8<-:- snip -:-8<--
[EMAIL PROTECTED]:/$ gij-3.0 --help
Usage: gij [OPTION] ... CL
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states
> >> that such things happen when you use JNI with GPL code. Anyway, I'm
> >> neither a laywer, nor in any way experienced enoug
Hi. Just a few more notes on this.
> Java libraries must depend on the needed working runtime
> environments, including the virtual package names of working
> versions of the "unfree" bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
> Are there any other requirements? Should /lib and /usr/lib be searched
> or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
"normal" application libraries).
In particular, java policy also
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
> Ok, I don't actually mind. The only real argument I have is that it
> looks better, if you have all requirements defined with comandline
> arguments, not environment variables. But ok... neither gij-3.0 nor
> gij-wrapper-3.0 have a -classpath op
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
> Chapter 2. Policy
>
> Packages written in Java are separated in two categories: programs
> and libraries. Programs are intended to be run by end-users.
> Libraries are intend
Hallo Grzegorz,
Only a reply to the list, as this won't help before the sarge release.
* Grzegorz B. Prokopski wrote:
>The problem is that jikes privides wrappers which depend on every
>possible JVM in Debian. [...]
>Probably the proper fix for that would be that creation of wrappers
>should be o
Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
>2.6. Java programs
[...]
>Applications may honor the user set JAVA_HOME evironment variable,
>while looking for a useable java virtual maschine. If so, this must
>be clearly stated in the manpage and, if possible, a
Hallo Ben,
* Ben Burton wrote:
>> >Then why push for $JAVA_HOME, which suffers from the same problem?
>> Because I think there are a lot of programs, which rely on the
>> 'java.home' property to be set. Here is for example the result on
>> going thru the ant tasks. ant is IMO one of the important
> If the discussed proposal is used, this will be the only way to do it.
>
> -> A 'ant environment', which will use jikes as a compiler, will set
> the ANT_BUILD_COMPILER to jikes and ant will use jikes as a compiler.
What if I don't want to use ant?
The current jikes-* wrappers let me drop in
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states
> >> that such things happen when you use JNI with GPL code. Anyway, I'm
> >> neither a laywer, nor in any way experienced enoug
Hi. Just a few more notes on this.
> Java libraries must depend on the needed working runtime
> environments, including the virtual package names of working
> versions of the "unfree" bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
> Ok, I don't actually mind. The only real argument I have is that it
> looks better, if you have all requirements defined with comandline
> arguments, not environment variables. But ok... neither gij-3.0 nor
> gij-wrapper-3.0 have a -classpath op
Hallo Grzegorz,
Only a reply to the list, as this won't help before the sarge release.
* Grzegorz B. Prokopski wrote:
>The problem is that jikes privides wrappers which depend on every
>possible JVM in Debian. [...]
>Probably the proper fix for that would be that creation of wrappers
>should be o
Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
>2.6. Java programs
[...]
>Applications may honor the user set JAVA_HOME evironment variable,
>while looking for a useable java virtual maschine. If so, this must
>be clearly stated in the manpage and, if possible, a
Hallo Ben,
* Ben Burton wrote:
>> >Then why push for $JAVA_HOME, which suffers from the same problem?
>> Because I think there are a lot of programs, which rely on the
>> 'java.home' property to be set. Here is for example the result on
>> going thru the ant tasks. ant is IMO one of the important
72 matches
Mail list logo
