ams before but never Java. Are
> > there any small packages out there which use JNI I could look at for
> > examples?
Well, I can offer libreadline-java for you to look at, but that of course
doesn't mean it's done the Right Way.
Ben. :)
- --
Ben Burton
[EMAIL PROTECTED] | [
of splitting things but I also know that all people
> are not. :)
I do believe in this instance that neither the java classes nor the C library
make sense without the other.
Ben. :)
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
To love oneself i
and
libfoo-jni containing the C library.
I don't see any particular need to favour only one of these options as policy;
I can see circumstances where each option (splitting vs not splitting) has
its benefits.
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finge
pped in a separate architecture-specific package.
> The package containing Java bytecode should depend on this
> package.
>
Perhaps I missed part of the thread there?
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
Questions
> This is fixed in the just uploaded version.
>
> Moved it to the library section too.
Thanks very much. :)
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
I'm the thing that fundamentalist Christians cringe over.
egardless of what the
/usr/bin/javac alternative is set to. But that's just my personal
preference.
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
Bad artists always admire each others work.
- Oscar Wilde
-
n/java alternative.
Note that this wrapper script would need to see if any -Djava.library.path
arguments are *already* being passed and if so then simply augment that list
with /usr/lib/jni.
Thoughts?
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PRO
the JNI libraries (well, unless you explicitly load them in
your own Java sources).
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE9nnkWMQNuxza4YcERAkc8AKCZ/cXDN8XEQAv
sspath.
Anyway, after rereading the archives it seems Ola asked you to submit this as
a wishlist bug to java-common, so presumably this is the next step you need
to take if you want /usr/share/java/ext incorporated in java policy.
b.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Pub
> But, is there no more direct way of accessing the $LANG var from within the
> Java program itself?
You could try System.getProperty("user.language"), but I'm not sure how
portable this is, or how well it relates to $LANG (my system returns "en" and
my $LA
> Could you please tell me how to compile my.java with two jars? What is the
> command line? Say, "javac -classpath a1.jar;a2.jar my.java", is it correct
> in windows? What is it in linux?
Just replace your semicolon with a colon:
javac -classpath a1.jar:a2.jar my.java
Be
now so that, assuming the proposal does get accepted,
the groundwork is ready to begin (3) when the policy update takes place.
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
Most people are other people. Their thoughts are someone else'
> I want people to second this wishlist so I can add it.
*sigh*.. does nobody but me care about JNI?
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
All art is quite useless
- Oscar Wilde
--
To UNSUBSCRIBE, email to [EM
e the JVMs support this single place by including it
in the default java.library.path.
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
Why can't they have gay people in the army? Personally, I think they are
just afraid of a thousand gu
st like it's a simple matter to find which jars to add
to $CLASSPATH (look in java policy or just see where a package installs its
files).
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
If your thesis is utterly vacuous, /
Use first-order
l of this back in September/October 2001,
you might want to browse the archives if you're interested in people's
earlier reponses.
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
How can anyone have an understanding of the virgin if
y.path=/usr/lib/jni. Then
call your real java runtime command with your new modified set of options.
Ben.
- --
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
There is only one thing in the world worse than being talked about, and
that is not being talked
is on
# the JNI search path.
#
# Variable $javaRuntime should be modified to suit the particular java
# runtime being used.
#
# Usage: As for the particular java runtime being used.
#
# Copyright (C) 2002 by Ben Burton <[EMAIL PROTECTED]>
use strict;
# The real java runtime:
my $javaRun
> Is this the concensus? You have been my only response so far. Since
> JAVA_HOME is so common, I hope mention of it would be made in the java
> policy documentation.
Well I agree with Andrew. AIUI, JAVA_HOME is not appropriate for java
interpreters such as gij or some of the other free alterna
> > According to the Java policy, packages that provide java1-runtime must
> > support the the complete java runtime environment.
Well, AFAICT (looking at policy linked to www.debian.org), the Java policy
isn't particularly explicit. Section 2.1 states:
Java virtual machines must provide java
> If you have better definitions on how to define java1-runtime and/or
> java2-runtime, I'm grateful for such propositions.
If AWT / GUI stuff is a particular problem (which is my understanding),
I think it would make sense to define virtual packages java1-awt-runtime
(and possibly java2-swing-ru
> If I may make a proposal, as someone who's just a
> lurker here, I'd say remove the 'provides
> javax-runtime' tag from the free VM releases that
> obviously lack the functionality of the tagged JDK
> release, according to japitools. But only allow Java
> programs to get into 'debain free' if th
> I'd like to point out that I wasn't advocating that
> the debian maintainer tracks all VMs available for
> debian all the time. Just that she specifies a (i.e.
> at least one ;) free VM that the application works
> with in order to be in 'debian-free'.
Mm.. what worries me about this is that i
> This is where I stand right now with at least one package: I cannot
> depend on java1-runtime because two of the three packages that provide
> it *don't work*. By leaving the java1-runtime tag on the incomplete
> VM packages, I'm required to maunally validate these packages
> continuously or si
> Shouldn't it be:
>
> Depends: j2sdk (>= 1.3) | java-common (or java2-common?)
Hi. I think (assuming the package requires java2 to run) that what you
want is:
Depends: j2re1.4 | java2-runtime
Only the JVMs themselves actually depend on java{,2}-common. The apps
depend on java{1,2}-runtime
from wishlist to something more important, and then let the JVMs catch up?
Ben. :)
- --
Ben Burton
[EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
When I started watching my behavior and seeing how I would control
people, and how they would control me, it was awareness. I want awarene
> Do you know why they have not done anything. Have they responded at all?
The kaffe maintainer wrote when I sent the second (source-level) patch and
said he'd take a look. The sablevm maintainer replied to my post from
yesterday; you've seen that. The jdk1.1 and j2se1.4 maintainer I've heard
n
Hi. As requested, a source patch for java-common is included below. It's
also available at http://people.debian.org/~bab/java/jni-policy.diff .
Ben. :)
--- java-common-0.16/policy.xml 2002-09-26 00:53:03.0 +1000
+++ java-common-0.16.1/policy.xml 2003-02-09 23:16:23.0 +11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
*grin* .. *prod*
The /usr/lib/jni proposal is now implemented in sid for gij and sablevm,
patches are still available for other JVMs, a policy patch has been provided
and this has received two seconds and no disputes.
Ben. :)
- --
Ben Burton
> I second this policy change. I would like one more to be able
> to apply it.
Seconded.
b. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I second this policy change. I would like one more to be able
> to apply it.
Seconded again, this time with a signature. :)
b.
- --
Ben Burton
[EMAIL PROTECTED]
Public Key: finger [EMAIL PROTECTED]
There is much to be said in favour of
Hi. I've just been converting an app to use C++-style casts instead of
C-style casts and I've come across a nasty problem.
If you use a C++ dynamic_cast complied with g++-3.3 within a native Java
method, the blackdown JVM (1.4.1) crashes.
I've attached three very short sample files that illus
> If you use a C++ dynamic_cast complied with g++-3.3 within a native Java
> method, the blackdown JVM (1.4.1) crashes.
Btw, further investigation suggests that this problem might be fixed by
rebuilding the blackdown JVM with gcc-3.3. Stephen, would this be possible?
Thanks - Ben. :)
--
To
> Nevertheless it's the libstdc++ issue. Your code works fine with our
> gcc-3.2 build of 1.4.1.
Rightio, so it seems the debian j2se1.4 package does need a rebuild then.
Thanks - Ben. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL P
> I'll probably try that, but I'm loathe to waste the time
> if it turns out I'm just doing something stupid.
I can't tell you how to determine which gcc a binary was compiled with,
but I can tell you that you're not just doing something stupid.
Downloading a -gcc3.2 tarball from Blackdown certai
> BTW, I've not seen any package that usees the versioned JAR - so
> it obviously is not useful.
This is not a valid argument. Just because debian packages don't use a
feature doesn't mean users aren't using the feature with their own
home-grown software.
Ben. :)
--
To UNSUBSCRIBE, email to
> But I think the process should go in the other direction: Instead of
> specifing something and waiting for people to implement it we should
> document what has been implemented and is working well.
This is not necessarily true; take as an example the /usr/lib/jni
proposal. Although pretty mu
> The question is:
> Is /usr/lib/jni in the library path?
>
> If no, shouldn't it be?
Yes, it should be - this is in Java policy. It's in the library
path for gij and a couple of other JVMs but not the Blackdown JVM.
Please report this to the Blackdown maintainer as a bug.
Ben.
--
To UNSU
> I'll re-do some tests but I'm sure it did not work neither with gij nor
> kaffe!
Are you using gij-wrapper (and not just gij)?
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> [EMAIL PROTECTED]:~/docs/java/gnome$ LD_LIBRARY_PATH=/usr/lib/jni gij-3.3 First
> is OK :)
Hmm, what happens if you use LTDL_LIBRARY_PATH instead of
LD_LIBRARY_PATH? This is essentially what the gij-wrapper script is
doing.
If LD_LIBRARY_PATH works but LTDL_LIBRARY_PATH does not then the wrap
> > JAVA_HOME=/usr/lib/j2se/1.4
>
> Would there be a way of making this bit magic? i.e. following the
> /usr/bin/java symlink?
This is dangerous - even if you jave j2sdk1.4 installed, /usr/bin/java
might still point to kaffe, gij, etc. I'd stick with a hard-coded path,
especially if it require
> I agree with this. IMO a java jar should be handled the same as a
> binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version / soname. All you can guarantee to get is a release version,
which may or may
Disclaimer: I haven't been following the kaffe situation at all; I use
gij for my primary DFSG-free JVM.
> I think we should fix and test your Kaffe 1.1.1 packages and do an NMU
> if Ean does not answer within the next few days.
Doesn't a few days seem abnormally short notice for such a major N
> You can see that I introduced some problems because I'm not familiar
> with the package but as I am on holliday, I'm trying to help Debian the
> more I can;)
Oh, I appreciate your work. I wasn't arguing against your packages - I
was arguing against the proposal to do a new upstream NMU fo
> Ant will move to main as soon as a Kaffe 1.1 package is uploaded.
This is wonderful news.
> Upload Kaffe 1.1 and you'll see faster results than rewriting Makefiles. :-)
Indeed. Although since maintainers have happily sat for a year on ant
build systems without writing a few makefiles, I'm su
> Would it not be better to work on getting the free JVMs to the point where
> they can run ant? (or if ant can be adjusted to be more friendly to these
> JVMs)
Sure, but that will take much longer and it's a task at which a random
java package maintainer would be far less effective. As the jyth
> Yes, maybe this is short. On the other hand, one can take into
> consideration that the last message of Ean about upgrading (at that time
> it was to kaffe 1.1.0) was almost two month ago (see #196867). And there
> has been a mail on this list (which I assume he should read) about
> problems
> Kaffe has RC bugs which are open for 3 months (not counting your bug
> report about /usr/lib/jni) - all of them either include a patch or are
> easy to fix. Kaffe has been removed from testing because of this and now
> keeps other Java packages (like jikes, see #203054) from moving to testing
> Additionally, I still question the wisdom of the shared JNI directory.
> >From what I understand, there are different versions of JNI and you
> cannot count on the idea that all JNI libraries are simply going to work
> with all VMs. It's not clear to me that different versions of JNI can
> even
> Additionally, I still question the wisdom of the shared JNI directory.
> >From what I understand, there are different versions of JNI and you
> cannot count on the idea that all JNI libraries are simply going to work
> with all VMs.
Further to my last email, I should add that this is not an iss
Hi. I think there are some interesting ideas in this proposal, and
there are also some ideas that are more concerning to me.
> It would be nice, if this, and the transition (if it should
> happen...), are over before sarge is released.
Given that we are this close to freeze, I would be *very* r
> Therefore we need alternatives for each combination of virtual packages:
> VM -> Provides: net, nio
> -> provides alternatives for java-nio, java-net and java-nio-net
Wouldn't this mean that if a JVM provides k packages of the form java.*,
then it must provide 2^k different virtual packages? T
Just a note:
> People will always complain, as long as the free java implementations
> are not equivalent to sun's on all accounts. Frankly, as long as they
> don't want to put the little extra effort, and work with us to fix the
> issues (for example by implementing and contributing the missing
> Anyway, this gcj isn't in debian yet.
Hmm? apt-cache show gcj
Or are you talking about a different version of gcj? Or am I
misunderstanding your comment completely?
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> javac can also be called during package building.
FWIW, I think having a package build relying on /usr/bin/javac is a very
bad idea. You want to be absolutely sure that a package builds out of
the box, and IMHO this means you should explicitly build-depend upon
*and* call a complier that you k
> > Packages, which want to contribute a alternative for /usr/bin/java
> > and its manpage must provide java-runtime. The alternative must
> > accept the option '-classpath', which sets the classpath and
> > autmatically adds the right rt.jar. The must depend on java-common.
>
> You need to speci
> I think we should distinguish are two different kinds of builds:
> 1) by the Debian build daemon
> 2) by a user that downloaded the package source
Both of these must still work out of the box. In particular, as a user
I should be able to apt-get source foo-java and just build it without
ha
> > This is somewhat more difficult to arrange with command-line options.
>
> java -classpath foo.jar:bar.jar:$CLASSPATH
Heh. :)
*slap*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >Can we use $CLASSPATH instead of -classpath? From my experience making
> >packages work with both free and proprietary JVMs, setting $CLASSPATH
> >before calling the java runtime (instead of passing -classpath, -cp,
> >whatever) has caused the least breakage.
>
> With some clear idea about *w
> >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 packages,
> which should be made
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
> 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
> 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
> >>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
> 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
> >> 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
> 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. :)
> 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
> >I'm not really comfortable with the idea of "don't test, just assume it
> >works until someone tells you otherwise". Yes, it happened with flex
> >but that was a once-off. With this java proposal it will become
> >institutionalised.
>
> It is already institutionalised.
> ...
Yes, but in the
> Currently almost every java app is in contrib: eclipse, tomcat, ant.
Running a quick check, there are 48 packages that depend on
java-virtual-machine (which from policy I thus assume to be java apps or
libs).
28 in contrib;
2 in non-free;
18 in main.
That's only about 60% in contrib, certainl
> > Programs must depend on the needed runtime environments, including
> > working versions if the bin/java unfree interfaces.
>
> bzzt! ;)
>
> this 'let's make free software in debian depend on non-free software'
> proposal is incompatible with debian's goal, afaik. turn that into a
> 'may dep
> BTW, what tool did you use?
apt-cache showpkg java-virtual-machine
(and look in the Reverse Depends section).
Note that this pulls in Recommends: j-v-m and Suggests: j-v-m as well,
which is presumably why my search picked up more packages than yours. In
particular my search picks up a number
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
> >I'm quite happy with this suggestion as well (must -> may for non-free
> >JVM dependencies). If at least one of the dependencies is satisfied
> >- even if this is selected from a list of only free JVMs - then the
> >app will presumably run successfully and so there's no problem if
> >non-free
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the
> 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
Hi. Just a couple of notes re the findjava and java-config scripts.
Since the proposed policy mandates that programs use both these scripts
(section 2.6), I would really like to see working implementations of
each of these *before* we look at making this proposal into policy.
>Packages, whi
> Yes: The findjava script will let you *overwrite* your 'known working
> VMs'
Well, so did that tiny 'for' loop (by allowing the user to set $JAVA).
> and will let the user choose one default VM, which will be used,
> when it is include in your list of 'known working VMs'.
Rightio.
> 'need to
> >> and will let the user choose one default VM, which will be used,
> >> when it is include in your list of 'known working VMs'.
> >Rightio.
>
> I take that as an agreement?
Not necessarily, just an understanding of what you mean. I'm still
uncomfortable with using a hand-rolled system here w
> >If all you want is for the user to specify a "default JVM", then why not
> >just let this default JVM be the alternative /usr/bin/java, just like it
> >is now? [...]
>
> IMO the alternative system can only be used in two cases:
> * when all apps for the alternative are similar enough to not c
> IMO you don't need to use teh alternative system, if you just 'work
> around' it. YMMV...
Well, IMO the alternative system exists so that users don't need to
learn how each different package works around it in its own different
way. Instead it provides a standard system for setting system-wide
> >Well, IMO the alternative system exists so that users don't need to
> >learn how each different package works around it in its own different
> >way. Instead it provides a standard system for setting system-wide
> >defaults.
>
> So we understand something differen when we talk about the
> 'alt
> IMO the 'alternative system' is not used for this. Looking what
> alternatives are installed in my system, they are either
> * editors or other interactive things (telnet, www-browser)
> * different version of the same tool (autoconf, gcc, shells)
> * apps which do not require commandline apps (
> What is findjava going to be written in again? Perl? That would suck if
> that's the case. Surely we can find a way to launch a Java language
> runtime without using the Perl language runtime.
On the other hand, Perl deals with things like quoting and other
problems resulting from unanticipated
> FWIW, the black magic is "$*" (including the quotes).
Do you mean "$@"? If so, this (and "$*") become somewhat more
troublesome when you need to modify command-line arguments or insert
your own.
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Co
> Bash (that's what it is written in currently. But I guess, that plain
> sh isn't different here) will seperate all 'words' in your
> commandline, if you don't quote them. Words in this case means,
> everything, which is seperated by one of the chars in $IFS.
Right. So when you have single comm
FWIW:
> Blackdown is a enchanced linux port of the sun VM. But the last
> debian packages are a little bit outdated ...
and broken - they're still using gcc2 builds, which can (in my experience)
cause apps using C++ native libraries to crash randomly and frequently.
If you're planning on using
Hi.
> There seems to be no more questions, but unfortunatelly nonone has
> said something like 'do it' or 'file bugs with patches' or 'go
> testing' or whatever until now.
My only comment is that since sarge is purportedly so close to freeze
and since this is more or less a complete policy rewri
Hi.
> In short, can you tell me the 'correct' options as far as interpreters are
> concerned? (Actually, _any_ help would be appreciated!)
Depends on what sorts of options you're trying to use. For adding
something to the classpath, setting $CLASSPATH in the environment seems
to be handled well
> I think the dependency on junit sort of makes sense since it can be
> considered a basic tool for java developers. The same cannot be said of
> jython and antlr.
On the other hand, having jython depend on (or recommend or suggest) ant
is quite nonsensical as well, since ant is not really a to
Let me preface this by stating that I know very little about ant, and I
have no idea how ant specifically interacts with jython.
Jython itself is an implementation of the python scripting language.
The python package does not suggest every package that uses python
scripting, nor does it suggest e
severity 210716 important
thanks
> > #210716 jython causes kaffe to fail with assert error
> >
> > ,
> > | Version: 1:1.1.1-1
> > |
> > | > After removing the JNI lines from jython shell script (see
> > | > issue #207998) kaffe dies with kaffe-bin: mach
> Many thanks for your work, I'm about to close some bugs from kaffe, many
> thanks.
It looks from Dalibor's mail that the bugs were closed only in upstream
kaffe. If the bugs are still present in debian, they must remain open
in the debian BTS. You can add the tag fixedupstream to let people k
reassign 210716 gcj-3.3
thanks
> So basically, jython has been compiled by a buggy compiler ;)
Confirmed: I've just uploaded a new jython package that builds using
jikes-gij instead of gcj, and the problem goes away. Of course jython
still crashes with kaffe, but that's just the old "specifying
Hi.
> Applications must provide one or more executable wrapper script(s) in
> /usr/bin. They must run without specific environment variables (see
> Policy 10.9), for instance JAVA_HOME or CLASSPATH. They must respect the
> Policy rules for executables (for instance a manual page per executable
> Java library packages must depend on other library packages if they
> can't be used without them. If other libraries are only required by
> parts of the library, they should suggest the required library package
> instead.
This paragraph really seems like it's just restating standard
debian p
Hi. Further on this proposal:
> Java libraries must depend on the needed runtime environment
> (java1-runtime and/or java2-runtime) ...
I do not like deleting this requirement. Although there are some
serious problems with it (such as different libraries working to
different degrees on differe
Hi again.
> I think we can assume that all libraries work with java2-runtime, at
> least I have not seen one that requires java1-runtime and does not work
> with "JDK 1.2 and above". The next problem is that java2-runtime means
> "JDK 1.2 core classes and above" but there's no way to specify "
> Non of them even implements the full JDK 1.1 API so they also shouldn't
> provide java1-runtime unless you change the definition of the
> java1-runtime virtual package.
We've already had this argument. The java*-runtime virtual packages
are a loosely defined system for which Jan already has
Regarding jython and libreadline-java, I think we've had a small
communiation breakdown. What I meant is that there are packages that
do not require java2-runtime, i.e., that only use the 1.1 API.
Thus the *absence* of java2-runtime in the depends list is
an indication that the package should wor
1 - 100 of 332 matches
Mail list logo
