>libnbio-java 3
This package doesn't exist in the archive any more (it hasn't in years).
I guess popcon is reporting on what people have installed regardless of
whether the package is available any more.
Anyway, libnbio2-java is in main.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
pg
On Thu, Mar 04, 2004 at 01:14:56PM +0100, Arnaud Vandyck wrote:
> > And 7.4 details how the QA handles orphaning packages maintained by
> > inactive maintainers.
>
> I'd like someone to point me where is the reference of the ITH?! It's
> the second time I read about ITH but I don't know where to s
> > >For #8:
> > >We should add that all jars should have a manifest (but without
> > >Class-Path). Ant can autogenerate a manifest, or does, I forget?
> >
> > BTW: I never yet touched Manifests, what are they actually for? :)
>
> Manifests are a child of java applets. Sun needed a place to put
> I'm trying to install Tomcat 4.1.24-2 from the unstable section,
> and I'm running into a wall. It depends on "j2re1.4" or
> "java2-runtime", neither of which seems to exist. I have
> installed the Sun JDK 1.4.1_02 manually, so there actually is a
> Java 1.4 runtime, and I i
> I'm trying to install Tomcat 4.1.24-2 from the unstable section,
> and I'm running into a wall. It depends on "j2re1.4" or
> "java2-runtime", neither of which seems to exist. I have
> installed the Sun JDK 1.4.1_02 manually, so there actually is a
> Java 1.4 runtime, and I i
> > Just tried that and it seems to work; there're a few
> > nuissances with this option, but no showstoppers.
>
> Pardon, what does 'nuissances' mean? I can't find such a word in my
> dictionary.
Just a misspelling of nuisance, I think. :)
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Perso
> > Just tried that and it seems to work; there're a few
> > nuissances with this option, but no showstoppers.
>
> Pardon, what does 'nuissances' mean? I can't find such a word in my
> dictionary.
Just a misspelling of nuisance, I think. :)
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Perso
> From policy:
> "Java libraries must depend on the needed runtime environment (java1-runtime
> and/or java2-runtime) but should not depend (only suggest)
> java-virtual-machine."
Right. I will use this:
Depends: kaffe | java1-runtime, java-common
Suggests: java-virtual-machine
I think
> From policy:
> "Java libraries must depend on the needed runtime environment (java1-runtime and/or
>java2-runtime) but should not depend (only suggest) java-virtual-machine."
Right. I will use this:
Depends: kaffe | java1-runtime, java-common
Suggests: java-virtual-machine
I think tha
Ok... I've gotten a lot of answers on this thread, which I REALLY
appreciate. This is what I love about Debian. :-) I just want to take
one last pass at my question, to make sure everyone's in agreement.
Parts of this thread (which is now a week+ long) have gotten lost along
the way :), so to su
Ok... I've gotten a lot of answers on this thread, which I REALLY
appreciate. This is what I love about Debian. :-) I just want to take
one last pass at my question, to make sure everyone's in agreement.
Parts of this thread (which is now a week+ long) have gotten lost along
the way :), so to su
> If you want to specify which of a set of real packages should be the
> default to satisfy a particular dependency on a virtual package, you
> should list the real package as an alternative before the virtual one.
>
> If kaffe works for Kenneth, I guess his Depends line is fine. By
> If you want to specify which of a set of real packages should be the
> default to satisfy a particular dependency on a virtual package, you
> should list the real package as an alternative before the virtual one.
>
> If kaffe works for Kenneth, I guess his Depends line is fine. By
> $ apt-cache show kaffe
> ..snip..
> Provides: java-virtual-machine, java-runtime, java1-runtime
>
> So, kaffe provides java-virtual-machine. You don't need to write dependency
> for kaffe.
Ok, that makes sense.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Personal Homepage: http://www.sk
> $ apt-cache show kaffe
> ..snip..
> Provides: java-virtual-machine, java-runtime, java1-runtime
>
> So, kaffe provides java-virtual-machine. You don't need to write dependency
> for kaffe.
Ok, that makes sense.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Personal Homepage: http://www.sk
> > You should list the working package first :
> >
> > working-java | java-common
>
> And it should look like this instead.
>
> working-jvm | java-virtual-machine.
Ok. I will change it to:
Depends: kaffe | java-virtual-machine, java-common
Is this correct?
KEN
--
Kenneth J. Pronovic
> > You should list the working package first :
> >
> > working-java | java-common
>
> And it should look like this instead.
>
> working-jvm | java-virtual-machine.
Ok. I will change it to:
Depends: kaffe | java-virtual-machine, java-common
Is this correct?
KEN
--
Kenneth J. Pronovic
On Sat, Nov 16, 2002 at 01:10:35PM -0700, Tom Tromey wrote:
> Kenneth> The error I got from gij (below my signature) it a little out
> Kenneth> of my league.
>
> You're getting an UnsatisfiedLinkError. That probably means that some
> native code wasn't loaded by the application. Without knowing
On Sat, Nov 16, 2002 at 01:10:35PM -0700, Tom Tromey wrote:
> Kenneth> The error I got from gij (below my signature) it a little out
> Kenneth> of my league.
>
> You're getting an UnsatisfiedLinkError. That probably means that some
> native code wasn't loaded by the application. Without knowing
[I think this is still topical to both debian-mentors and debian-java.
Someone tell me if they want it moved to one or the other...]
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work wi
[I think this is still topical to both debian-mentors and debian-java.
Someone tell me if they want it moved to one or the other...]
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work wi
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work with gcj? Could you please file a bug report?
> http://gcc.gnu.org/bugs.html
> That way we at least know about the issue.
>
> Also Kaff
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work with gcj? Could you please file a bug report?
> http://gcc.gnu.org/bugs.html
> That way we at least know about the issue.
>
> Also Kaff
> Erm, i think it is even worse, i think that the users would need to
> install the j2sdk1.3 package or else it will be unusable. This also
> means that your package will never enter testing, i think, or maybe
> there is some kind of override for contrib/non-free packages. Also, the
> j2sdk1.3 is a
> Last i knew, j2sdk1.3 is not part of debian, be it in main, contrib or
> non-free, because it is not possible for us to distribute it because of
> the licencing issues.
>
> Because of that, this particular dependency will never be really
> satisfied, the auto builders will not be able to build
> Erm, i think it is even worse, i think that the users would need to
> install the j2sdk1.3 package or else it will be unusable. This also
> means that your package will never enter testing, i think, or maybe
> there is some kind of override for contrib/non-free packages. Also, the
> j2sdk1.3 is a
[I'm cross-posting to debian-java and debian-mentors, because I'm not
sure whether this is a Java question or a packaging question. Please
CC me on replies, if possible.]
Can anyone suggest why libnbio2-java's build dependency on j2sdk1.3
cannot be satisfied on all 13 platforms?
http://qa.deb
> Last i knew, j2sdk1.3 is not part of debian, be it in main, contrib or
> non-free, because it is not possible for us to distribute it because of
> the licencing issues.
>
> Because of that, this particular dependency will never be really
> satisfied, the auto builders will not be able to build
[I'm cross-posting to debian-java and debian-mentors, because I'm not
sure whether this is a Java question or a packaging question. Please
CC me on replies, if possible.]
Can anyone suggest why libnbio2-java's build dependency on j2sdk1.3
cannot be satisfied on all 13 platforms?
http://qa.deb
> >>I maintain libnbio-java, which is a JNI non-blocking socket IO package
> >>for Java. My current .deb is for upstream version 1.5. The upstream
> >>maintainer has just released version 2.0, and the only difference from
> >>version 1.5 is that the package name changed from mdw.java to seda.java
> >>I maintain libnbio-java, which is a JNI non-blocking socket IO package
> >>for Java. My current .deb is for upstream version 1.5. The upstream
> >>maintainer has just released version 2.0, and the only difference from
> >>version 1.5 is that the package name changed from mdw.java to seda.jav
I maintain libnbio-java, which is a JNI non-blocking socket IO package
for Java. My current .deb is for upstream version 1.5. The upstream
maintainer has just released version 2.0, and the only difference from
version 1.5 is that the package name changed from mdw.java to seda.java.
Does anyone h
I maintain libnbio-java, which is a JNI non-blocking socket IO package
for Java. My current .deb is for upstream version 1.5. The upstream
maintainer has just released version 2.0, and the only difference from
version 1.5 is that the package name changed from mdw.java to seda.java.
Does anyone
> I find myself with a need for the NBIO package from:
>
>http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> which implements non-blocking socket I/O. It's sort of a precursor to
> the nbio functionality that's in the Java 1.4 beta, implemented on top
> of standard socket calls like poll().
> I find myself with a need for the NBIO package from:
>
>http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> which implements non-blocking socket I/O. It's sort of a precursor to
> the nbio functionality that's in the Java 1.4 beta, implemented on top
> of standard socket calls like poll()
> Hi, Kenneth!
Hi!
Boy, all of you who wanted to see how the Java package-building process
goes are sure getting to see a lot - mostly my mistakes. ;-)
I think my problem here is that the only .deb I have messed with before
was the mutt .deb, and I am beginning to understand that it does things
> Hi, Kenneth!
Hi!
Boy, all of you who wanted to see how the Java package-building process
goes are sure getting to see a lot - mostly my mistakes. ;-)
I think my problem here is that the only .deb I have messed with before
was the mutt .deb, and I am beginning to understand that it does things
> (1)Do you know 'lintian'? If not, please try it with following
> (2)Java package name is libXXX-java.
Both done and uploaded to the same URLs as before. There are now
no lintian warnings. The package name was changed as requested and
versioned 1.4-1.
> (3)Build-Depends field is incomplete.
> (1)Do you know 'lintian'? If not, please try it with following
> (2)Java package name is libXXX-java.
Both done and uploaded to the same URLs as before. There are now
no lintian warnings. The package name was changed as requested and
versioned 1.4-1.
> (3)Build-Depends field is incomplete.
> I mean that other than Java use LD_LIBRARY_PATH. So, LD_LIBRARY_PATH
> shouldn't be defined _system-wide_. I think LD_LIBRARY_PATH should be
> defined at _startup script_.
> For example, ant has startup script in /usr/bin/ant. If ant use JNI
> (in fact, it's not used), LD_LIBRARY_PATH is defined
> I mean that other than Java use LD_LIBRARY_PATH. So, LD_LIBRARY_PATH
> shouldn't be defined _system-wide_. I think LD_LIBRARY_PATH should be
> defined at _startup script_.
> For example, ant has startup script in /usr/bin/ant. If ant use JNI
> (in fact, it's not used), LD_LIBRARY_PATH is define
> I find myself with a need for the NBIO package from:
>
>http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> which implements non-blocking socket I/O. It's sort of a precursor to
> the nbio functionality that's in the Java 1.4 beta, implemented on top
> of standard socket calls like poll().
> I find myself with a need for the NBIO package from:
>
>http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> which implements non-blocking socket I/O. It's sort of a precursor to
> the nbio functionality that's in the Java 1.4 beta, implemented on top
> of standard socket calls like poll()
> >4) Is it my responsibility to ensure that the system-wide
> > $LD_LIBRARY_PATH includes /usr/lib/java (or /usr/lib/java/jni),
> > so that the JNI libraries are found?
>
> IMO, You should not defined it. Because JNI libraries are used by only
> Java applications. Java applicati
> IMO, You should not defined it. Because JNI libraries are used by only
> Java applications. Java applications should define $LD_LIBRARY_PATH
> when they are executed.
>
> regards,
>
> Takashi Okamoto
Thanks for all of the feedback. That's enough to work with for now.
KEN
--
Kenneth J.
> IMO, You should not defined it. Because JNI libraries are used by only
> Java applications. Java applications should define $LD_LIBRARY_PATH
> when they are executed.
>
> regards,
>
> Takashi Okamoto
Thanks for all of the feedback. That's enough to work with for now.
KEN
--
Kenneth J.
[Sorry for the long email; I have a lot of questions.]
> http://people.debian.org/~opal/java/policy.html/
> http://lists.debian.org/debian-java/2001/debian-java-200107/msg0.html
I did read the policy, and I have now looked over the JNI email thread.
I'm a little confused about how the policy
[Sorry for the long email; I have a lot of questions.]
> http://people.debian.org/~opal/java/policy.html/
> http://lists.debian.org/debian-java/2001/debian-java-200107/msg0.html
I did read the policy, and I have now looked over the JNI email thread.
I'm a little confused about how the policy
I find myself with a need for the NBIO package from:
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
which implements non-blocking socket I/O. It's sort of a precursor to
the nbio functionality that's in the Java 1.4 beta, implemented on top
of standard socket calls like poll().
Has anyone e
I find myself with a need for the NBIO package from:
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
which implements non-blocking socket I/O. It's sort of a precursor to
the nbio functionality that's in the Java 1.4 beta, implemented on top
of standard socket calls like poll().
Has anyone
> Perhaps one of these filter programs can be placed on
> the debian-java e-mail server and filter things centrally
> for all of us. Good idea, or bad?
This discussion has gone 'round and 'round on a number of the other
lists, in particular -curiosa and -security. It sounds like some spam
is alr
> > Is there any way to get this spam trash out of our e-mail list?
>
> The first I heard of this spam was the message from you - razor caught it
> for me and I never saw it.
>
> Since I installed it 2 months ago, it has caught 620 spam mails and had one
> false positive. I move the mails into a
> Perhaps one of these filter programs can be placed on
> the debian-java e-mail server and filter things centrally
> for all of us. Good idea, or bad?
This discussion has gone 'round and 'round on a number of the other
lists, in particular -curiosa and -security. It sounds like some spam
is al
> > Is there any way to get this spam trash out of our e-mail list?
>
> The first I heard of this spam was the message from you - razor caught it
> for me and I never saw it.
>
> Since I installed it 2 months ago, it has caught 620 spam mails and had one
> false positive. I move the mails into
54 matches
Mail list logo
