> So ... I'm CCing this to the debian-java list with a question: is it
> reasonable to name a package 'libsvn-java' if the jar file it ships is
> named svn-javahl.jar? I really don't like 'libsvn-javahl-java' as a
> name (reminds me of 'python-pyvorbis'), but if policy requires it,
> we'll use it.
> Yes, I wonder about that too. The jar file really is named svn-javahl,
> for historical reasons: there was once a second effort (now dead, I
> believe) to produce java bindings which were not "high-level".
>
> There is also an independent project out there, not affiliated with the
> Subversion
> > And none of the javadocs are actually generated. Does anyone have any
> > idea why this error is occurring, or what needs to be done to fix it?
>
> Can it be that you are trying to link a remote javadoc location for the
> core classe? Please (Build-)Depend on classpath-doc and link with the
>
Hi,
My newly packaged libcolt-java (which is in the pkg-java Subversion
repository) builds properly using dpkg-buildpackage, but when attempting
to build with pdebuild I get the following:
[javadoc] Fetching package list for external documentation set.
[javadoc] java.io.IOException: Stream c
> > You are proposing two distinct alternatives:
> >
> >- number of non-library packages depending on the VM
> >- if you install a certain VM, how many applications will you be able
> > to run with it
> >
> > The first is easier to measure, while the second would potentially be
> > mor
> >> I'd suggest a popcon based ordering. Reevaluate for every
> >> release / 6 months, etc. which should let us shuffle things
> >> around as necessary.
> >
> > We can also reevaluate just before the release.
> Before popcon (number of downloads), I would suggest number of non-library
> packages d
Hi Eduard,
Do you have a timeframe in mind for implementing -l 2 in svn-inject? We
could really use it in the pkg-java project, and would love to help get
it integrated. Do you have any objections to the currently proposed
patch?
cheers,
Charles
--
Eight
Hundred
Thousand
Men
Use
Burma-Shave
htt
> > A virtual package name is a functional label, not a product name.
> > Java is the name of an island and a natural language too.
> > I'm surprised if Sun can prevent use of a word in this way.
>
> A function that is used to call a runtime, compiler, etc of the Java(tm)
> language!
>
> Java? i
ng Project. Any oposition to me importing it into the repository?
cheers,
Charles
- Forwarded message from Charles Fry <[EMAIL PROTECTED]> -
Package: wnpp
Severity: wishlist
Owner: Charles Fry <[EMAIL PROTECTED]>
* Package name: libcolt-java
Version :
Upst
> I have problems to trust the way Sun is doing it. I understand it like
> "we'll deliver a real java implementation to those poor little free
> guys". I'd prefer a less commercial approach and a word from Sun to
> support free implementations (GNU Classpath and friends): promise not to
> sue them,
> > 2) I don't see the trademark problem. There are already virtual
> > packages that use the word java. What would be the difference
> > between continuing the same trend?
>
> There is a trademark problem. The java1|2 virtual packages were targeted
> to Sun's, IBM's and Blackdown JVM ver
> > I strongly oppose the classpath/java distinction for classpath vs.
> > non-free JREs and JDKs. Instead I propose dropping classpath-* as well,
> > and only using java-jre and java-jdk.
>
> So people that wants to use Java should install non-free software?
> That's not possible in Debian!
No,
> Note that I added a paragraph from a proposal from Stefan Gybas,
> modified by Ben Burton (see Bug#227587). Even if they did not really get
> a consensus, I think, with the change of the virtual packages to
> classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
> Stefan is good to
> > There was a recent message about Java 1 versus 2 runtimes in Provides
> > (if I remember correctly). I've brought this up before, suggesting that
> > those two be combined. Is there any reason not to combine the
> > java-runtime and java-compiler virtual packages? If not I suggest that
> > we p
There was a recent message about Java 1 versus 2 runtimes in Provides
(if I remember correctly). I've brought this up before, suggesting that
those two be combined. Is there any reason not to combine the
java-runtime and java-compiler virtual packages? If not I suggest that
we proceed to do so.
ch
> You are right. And what about moving all the packages in a packages
> directory?
>
> pkg-java/website
> /packages/trunk
> /branches
> /tags
Well, I don't personally see a lot being gained by that, other than
preventing those who check out all the packag
> I made some tests with svn-buildpackage and I really like it. The tool
> uses the layout (svn-inject -o PACKAGE_VERSION.dsc
> svn+ssh://[EMAIL PROTECTED]/svn/pkg-java/packages/):
>
> <...>
>
> The '-o' argument to svn-inject tells it not to upload upstream tarball
> in subversion repository.
A
> >We have some proposals about the Debian-Java policy changes that
> > includes:
>
> > - java libraries can go to main if they can be built with free VM;
Does this also mean that it is no longer required that a library be
runnable from a free VM? My libbcprov-java builds just fine, but the
t
I recently migrated the Bouncy Castle package (source package
bouncycastle, binary package libbcprov-java and libbcprov-java-doc, with
more to come) to the pkg-java repository, and made Debian Java
maintainers the maintainer.
I had spent a lot of time getting the package to build properly, and now
I can commit. :-)
Forgot the chmod after the local import. Try again, let me know how it
goes.
Charles
-Original Message-
> From: Arnaud Vandyck <[EMAIL PROTECTED]>
> Subject: Working on tomcat 5.5.x
> Date: Tue, 10 Jan 2006 17:34:46 +0100
> To: Debian Java
> Old-Return-Path: <[EMAIL PR
> >pkg-java / trunk /
> > tags / /
> > branches / /
>
> Hrmz, eh, right? It looks like it's:
> | tags-or-branches / /
>
> Which also happens to make much more sense. Oh, you changed that later I
> see, excellent.
Yeah, um, that's what I meant. :-)
Charles
-Original Message-
> From: Charles Fry <[EMAIL PROTECTED]>
> Subject: Subversion migration complete
> Date: Mon, 9 Jan 2006 14:41:52 -0500
> To: debian-java@lists.debian.org
> Old-Return-Path: <[EMAIL PROTECTED]>
>
> Greetings,
>
> I just completed t
Greetings,
I just completed the Subversion migration. You can checkout the trunk of
the new repository with a command like:
svn co 'svn+ssh://@svn.debian.org/svn/pkg-java/trunk' pkg-java
The branches and tags can be obtained similarly by changing trunk to
tags and branches. The entire reposit
Message-
> From: Charles Fry <[EMAIL PROTECTED]>
> Subject: Re: Alioth CVS Read-Only (was: Re: svn repository)
> Date: Mon, 9 Jan 2006 12:41:04 -0500
> To: Arnaud Vandyck <[EMAIL PROTECTED]>
> Cc: debian-java@lists.debian.org, [EMAIL PROTECTED]
> Old-Return-Path: <
t sure this is the right place. I already
> send a mail about the wiki there but never got a response. And I'm not
> sure they manage Alioth... If someone can Cc to a better location...
>
> Thanks
>
> Charles Fry wrote:
> >>+1, keep only the RELEASE_ tags.
> >
> +1, keep only the RELEASE_ tags.
>
> The directory layout seems ok to me. If there is a problem, we can svn mv.
>
> Many thanks for your work Charles,
In that case I'll plan to make the migration on Monday. I'lll send out
email 15 minutes prior to starting the move, then upon starting and
fina
> > I set up a sample repository at:
>
> (...)
>
> Great, thanks. You prevented the problems that made me give up by simply
> not converting the tagged releases we have of each package. So it'll be
> harder to find back a specific release this way, at least, those of
> before the migration. I'm n
> > I couldn't help but noticing that the virtual packages for Java runtime
> > environments are now java1-runtime and java2-runtime, while the Java
> > compilter virtual packages are java-compiler and java2-compiler. Would
> > it not be more consistent to have java1-compiler and java2-compiler?
>
> Great, thanks. You prevented the problems that made me give up by simply
> not converting the tagged releases we have of each package. So it'll be
> harder to find back a specific release this way, at least, those of
> before the migration. I'm not really sure what I think of this, but as
> other
> > > Normally packages are imported using svn-inject for each package, but
> > > then we would lose the CVS histories. I'd like to try to import using
> > > cvs2svn, but I'll need to research the minimum requirements of
> > > svn-buildpackage for this purpose.
> >
> > cvs2svn is problematic... It
I couldn't help but noticing that the virtual packages for Java runtime
environments are now java1-runtime and java2-runtime, while the Java
compilter virtual packages are java-compiler and java2-compiler. Would
it not be more consistent to have java1-compiler and java2-compiler?
Charles
--
Can'
> For what it's worth, here are my two cents on svn-bp layouts:
> - it's easier to only manage the debian/ dir in SVN (mergeWithUpstream)
>mode, and is really a clean way of working on Debian packages (except
>it forces you to have patches below debian/ instead of directly in
>the .di
> > > You've been elected to do the CVS to svn transition, congratulation! ;-)
> >
> > Accepted. ;-)
>
> I feel pity for you :)
Well, at this point I'm willing to work hard to avoid using CVS. ;-)
> > Alternatively we could work with upstream to get support for the
> > {trunk,tags,branches,...}
> You've been elected to do the CVS to svn transition, congratulation! ;-)
Accepted. ;-)
> If you can do the transition, you are welcome. Can you propose a
> directory layout for the svn repository (a layout we could use with
> svn-buildpackage or something).
Well, that makes it easy, as svn-bui
Is it just me, or is this entire thread a bit off topic for this list?
Charles
-Original Message-
> From: Luca Mannocci <[EMAIL PROTECTED]>
> Subject: Re: I have a problem help me
> Date: Sat, 12 Nov 2005 14:56:34 +0100
> To: debian-java@lists.debian.org
> Old-Return-Path: <[EMAIL PROTECT
> > This is a big field which needs even bigger investigation. The free
> > runtimes can load them but signed jars are still not supported (or was
> > this fixed lately...). Your best action would be to just test it with
> > kaffe or gcj or whatever and report any bugs you find.
>
> In the meantim
> > In order to be trusted, the security provider must be signed with a
> > key that was certified by the JCE Code Signing Certification
> > Authority (see Step 5 of the document above).
>
> So why can't we ship trusted root certificates for a Debian Code
> Signing Certification Authority, or trus
> > Can someone please comment on how we should proceed to obtain a JCE Code
> > Signing Certificate for Debian?
>
> Why can't we just install a trusted certificate in our own packages?
>
> It's not clear to me who should own the private key corresponding to
> the certificate, either. Perhaps yo
tests fail as the resulting jars need to be signed.
Can someone please comment on how we should proceed to obtain a JCE Code
Signing Certificate for Debian?
thanks,
Charles
-Original Message-
> From: Charles Fry <[EMAIL PROTECTED]>
> Subject: JCE Code Signing Certificate
> Da
Now that BouncyCastle[1] has been packaged for Debian[2], it is time for
us to move forward with Arnaud's suggestion[3] that we obtain a JCE Code
Signing Certificate[4] for Debian, in order to vouch for this and other
JCE Security Providers that Debian may provide.
The process is fairly straight-f
Last week I completed the first release of BouncyCastle:
http://debian.frogcircus.org/packages/
Unfortunately my primary sponsor has not yet found time to unload it.
Further, he maintains no Java packages himself, so I wondered if anyone
in the Debian Java community might be interested in spon
> I tried to test against the current classpath and kaffe CVS however it
> seems you didn't enable the whole testsuite in the build ? The single
> regression test during build fails for me also with a JDK 1.4 with:
>
>
>
> With free vms I only get the NPE for TSPTest. I couldn't found other test
00980915817952874371204983938256990422752107994319651632687982059210933395
got :
13628253036095457453781547057345293906187223953521072753797672813397452752475
If you encounter errors with other JVMs, please report them so that they can be
documented here, and ultimately fixed upstream.
-- Charles Fry <[EMAIL PROTECTED]>, Mon Aug 19 18:21:08 2005
signature.asc
Description: Digital signature
> > I have uploaded the Bouncy Caslte crypto library for Java to:
> >
> >http://debian.frogcircus.org/packages/
> >
> > Currently I am only creating libbcprov-java, as the other packages
> > need the jar to by signed by a trusted CA (libbcprov-java needs that to
> > in order to be used as a t
> - java1-runtime stands for Java1 (i.e. up to Java 1.2).
> - java2-runtime stands for Java2 (i.e. Java 1.3 and higher).
>
> - free VMs generally only provide java1-runtime (java-runtime is IMHO
> wrong or a typo).
Does this mean that bugs should be filed with packages which provide or
depend o
Hi,
I have uploaded the Bouncy Caslte crypto library for Java to:
http://debian.frogcircus.org/packages/
Currently I am only creating libbcprov-java, as the other packages
need the jar to by signed by a trusted CA (libbcprov-java needs that to
in order to be used as a trusted security provide
Hi,
I am trying to get the proper Depends line for the Bouncy Castle library
that I am packaging. Per the policy I found on the web, I depended on
java2-runtime, but then got a warning that
virtual-package-depends-without-real-package-depends. Looking at other
similar packages, I found that they w
> This way, your package could go to main, which is a very good thing.
> Another approach would be to build the package with some jdk's (1.4 and
> 1.5 are enough) and add jdk14 and jdk15 to the binary name.
>
> Maybe you can have a look at libpg-java I think it builds several jars
> for different
Hi,
I am currently working on bug #234048 to package Bouncy Castle Crypto, a
Java implementation of various cryptographic algorithms, for Debian. My
previous post about issues I have encountered went unanswered:
http://lists.debian.org/debian-java/2005/07/msg3.html
My primary dilema is th
> > I am attempting to contact anyone who has previously expressed an
> > interest in packaging a new Eclipse release for Debian. I grabbed
> > everyone from the ITA, as well as the Alioth project, and the Java list
> > for good measure. :-)
>
> I have CCed Michael Koch. He is working on 3.1 packa
Hi,
I am attempting to contact anyone who has previously expressed an
interest in packaging a new Eclipse release for Debian. I grabbed
everyone from the ITA, as well as the Alioth project, and the Java list
for good measure. :-)
Al Stone and I would like to work on packaging a new Eclipse releas
Hi,
What is the status of packaging Eclipse 3.1 for Debian? It seems like it
has been started many times, but never finished.
I would be interested in contributing, but would prefer to pick up where
others left of.
Charles
--
A man who passes
On hills and curves
Is not a man
Of iron nerves--
H
Greetings,
As a continuation of a [1]previous thread, I have returned to the task
of packaging the Bouncy Castle cryptography libraries for Debian.
1. http://lists.debian.org/debian-java/2004/04/msg6.html
First of all, I must express my appreciation for free-java-sdk and the
various tools
> > The only options I can think of are to make multiple packages, some
> > with signed jars and some with unsigned jars, or to provide both
> > jars in the same package. Note that this is not just a matter of
> > bein signed by the Legion of the Bouncy Castle; the certificate they
> > use was obta
> > Basically, the source of the Bouncy Castle Crypto libraries is
> > freely available, however the library jar file is signed by Bouncy
> > Castle, which is necessary for its use as a Java security provider.
>
> Bad.
>
> > As far as I can tell, in creating a Java library package, I want to
> >
Hi,
I sent this to debian-mentors with no response yet, and started thinking
maybe I should send it to debian-java instead. In any case:
I have started work on packaging the Bouncy Castle Crypto libraries
for Java (bug #234048). I think I have most everything in place for a
first stab, but I can'
56 matches
Mail list logo
