> If you are okay with this I will adopt it under the Debian Java
> Maintainers group coordination. I will take care of it and do an upload
> to show this in the next days.
Works for me -- thanks for looking after it.
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
retitle 315289 O: jython -- Python seamlessly integrated with Java
thanks mate
Hi all,
This is an FYI that I've just orphaned jython, as of version 2.1.0-21.
As when I orphaned it last June, my time is squeezed and I don't use java
much at all nowadays.
Again, see #315289 for a summary of releva
Last night I formally put the jython package up for adoption (#315289).
The reasons are because my time is rather more constrained than it used
to be, and because I have increasingly little to do with java these
days.
Since jython is a non-trivial piece of software, it seems worthwhile
outlining
Hi.
Since my name has come up in the context of kaffe co-maintainership a
few times now, I figure I might as well clarify my position.
I expect I would have neither the time nor the kaffe-specific expertise
to be a co-maintainer - my main use of kaffe is in testing other
packages under different
Hi.. does anyone happen to know if jikes-gij is coming back at some
point?
I ask because jython currently build-depends on jikes-gij, and I don't
want to have to hardcode the bootstrap classpath since this will
(presumably) keep having to be changed with even minor gij/gcj upgrades.
(Using gcj d
> And there is no upstream version for Python 2.3?
Not even for 2.2.
> Anyway, in this case, I guess the package should be called "jython2.1"
> instead of "jython". And maybe a meta-package providing Jython should be
> uploaded too?
It all seems a bit much, given that jython is a specialised ja
> So I suggest the leave the gij package as it is
FWIW, I agree with this (my reasons are given in the bug log).
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Yes, that makes it nice for users, but creates confusion for packagers.
FWIW, I would expect packagers to know what epochs are and how to deal
with them.
> I agree the extra source packages are a bigger pain that will be
> temporary, while the epoch solution is a mild pain that will last for
> >Actually, when I come to think of it since it's just a library, I don't
> >see why libtomcat4-java should worry about whether java2-runtime or
> >j2re1.4 is installed or not.
>
> That's actually exactly my opinion. But some people on the debian-java
> mailing list have a different opinion.
> This would take care of the automatic upgrade without the need of
> epochs, at the (temporary) cost of a few more packages. How long would
> the dummy packages need to stay?
I don't know what the convention is, but I tend to leave them in until
after the next formal debian release (in this ca
> > And this is my core problem with your proposal. You want to remove
> > j2/1-runtime, but you offer nothing whatsoever to replace it.
>
> No, I don't. Java applications must still depend on the required
> java*-runtime virtual packages, I just want this dependency removed for
> library pack
> Would it work if, say, classpath built a new package
> 'jikes-with-classpath' (whatever the name, but a new one), which
> 'Replaces: jikes-classpath' and 'Conflicts: jikes-classpath' ? Classpath
> could then keep its version number, and upgrades should still happen
> automatically.
No they
> And nobody is using the /usr/bin/javac alternatives anyway, right?
In jython, the jythonc utility uses /usr/bin/javac as its default java
compiler (just as it uses /usr/bin/java as its default java interpreter).
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscri
> It depends. If you want to make sure that all unstable users will
> get the wrapper updated - you'll have to add 2: epoh to current
> version.
>
> However, as I said, it's unstable after all and the wrappers don't seem
> to be changing their content anyway, so IMO you might as well decide to
>
I second this proposal (reproduced below).
> I propose to change the following paragraphs in section 2.3 of the
> Debian Java policy
>
> > Programs must have executable(s) in /usr/bin and be executable. They
> > can be Java classes (using binfmt_misc) or wrappers. In any case,
> > they
> > must r
> > Thus the *absence* of java2-runtime in the depends list is
> > an indication that the package should work on most JVMs in
> > debian. I would however expect these packages to run under
> > java2 as well.
>
> In my understanding the absence of java2-runtime means that a package
> that (solel
> > * j2/1-runtime does not garantee anything *at runtime*, so it is
>
> Right. That's exaclty the reason why I'd like to see them removed for
> library packages. But I guess I have already told this... :)
And this is my core problem with your proposal. You want to remove
j2/1-runtime, but you
> >I'm not asking for this dependency, but out of interest: what policy
> >violation?
> >
> >
> Section 7.2, the definition of Depends and Suggests:
Okay, I thought you had some other policy violation in mind beyond just
"depends is inappropriate here", which we both already agree it clearly is
> I'm not familiar with jython either. What I am assuming is the
> following: that the jython ant task provides a way to write build files
> for jython projects.
What do you mean "build files for jython projects"? Do you just mean it
provides an editor with jython syntax highlighting/etc? Or do
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
> 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
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 "
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
> 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.
> 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
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
> 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
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
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
> 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
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
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
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
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
> 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
> 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, 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.
> 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
> 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
> 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
> 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 (
> 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 (
> >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
> >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 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
> 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
> >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
> >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
> >> 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
> >> 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
> 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
> 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
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
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
> 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
> 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
> 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
> >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
> >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
> 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
> >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
> >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
> 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
> > 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
> > 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
> 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
> >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
> >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
> 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
> 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
> 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
> 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
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
> 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
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
> >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
> >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
> >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
> >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
> > This is somewhat more difficult to arrange with command-line options.
>
> java -classpath foo.jar:bar.jar:$CLASSPATH
Heh. :)
*slap*
> > 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]
> 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
> > 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
> > 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
> 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
> 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
> 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]
> 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.
1 - 100 of 332 matches
Mail list logo
