On 22.09.2009 16:42, Diederik de Haas wrote:
On 2009-09-22 Dalibor Topic wrote:
The raw data for them is at http://jdk-distros.dev.java.net.
cheers,
dalibor topic
Those packages will install java, but not as integrated to the debian system as
I want to.
wrong.
--
To UNSUBSCRIBE, email to
On 20.09.2009 13:43, Niels Thykier wrote:
Package: java-common
Version: 0.33
Severity: normal
I second this proposal using the java-{jre,jdk} for free and
java-{jre,jdk}-nonfree
for nonfree packages.
No, we should develop against a spec, not against a product. maybe this was more
wanted in
On 23.08.2009 23:38, Damien Raude-Morvan wrote:
It's linked to default-jdk switch to JDBC6
An issue report [1] is open upstream on this subject, but it's not fixed and,
sadly, proposed patch just add stubs methods.
Ubuntu [2] build hibernate with an explicit dependencies on GCJ compiler.
[1]
On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:
hello as I am working on my remotetea package, I build it using the
pbuilder.
and it seems that depending on default-jdk is not enought to produce
good documentation with javadoc. Indeed it do not find the
documentation for standard classes of
On 05.08.2009 18:26, Picca Frédéric-Emmanuel wrote:
Le Wed, 05 Aug 2009 15:52:34 +0200,
Matthias Klosed...@ubuntu.com a écrit :
On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:
hello as I am working on my remotetea package, I build it using the
pbuilder.
and it seems that depending
On 05.08.2009 20:02, Michael Koch wrote:
On Wed, Aug 05, 2009 at 06:26:44PM +0200, Picca Frédéric-Emmanuel wrote:
Le Wed, 05 Aug 2009 15:52:34 +0200,
Matthias Klosed...@ubuntu.com a écrit :
On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:
hello as I am working on my remotetea package, I
On 25.07.2009 05:47, Matthew Johnson wrote:
On Sat Jul 25 11:28, Mathieu Malaterre wrote:
On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsherm...@f2s.com wrote:
...
It would be extremely nice too if all wrap language would adopt the
same convention. So that toolkit such as VTK/ITK/GDCM wrapping
reassign 537290 classpath-common
thanks
No, there's nothing wrong with gcj-jdk. It defines a conflict with the current
classpath-common. What needs to be done: update classpath to 0.98, build cacao
using the new classpath, then decide what to do with the tools which are both
built by gcj-jdk
Andrew Haley schrieb:
In
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000587.html
Matthias Klose wrote:
The Ubuntu Java development team is pleased to announce completed
certification of OpenJDK 6 for Ubuntu 9.04, continuing Ubuntu's tradition of
integrating
Luk Claes schrieb:
Matthias Klose wrote:
According to the buildd logs the openjdk-6 6b14-4 build for mipsel did
finish on
Jun 20, but was not uploaded until now. Is there any interest within the
mips
porters on openjdk-6 on mips*, or should we just remove it from the archive
and
drop
Pierre Habouzit schrieb:
On Wed, Jun 24, 2009 at 11:39:16PM +0200, Matthias Klose wrote:
The current set of java packages (introducing java for hppa) in unstable
seem to
be ready for testing:
java-common 0.32
java-gcj-compat 1.0.80-5
gcj-4.4 4.4.0-8
gcc-defaults 1.87
Afaics only
The current set of java packages (introducing java for hppa) in unstable seem to
be ready for testing:
java-common 0.32
java-gcj-compat 1.0.80-5
gcj-4.4 4.4.0-8
gcc-defaults 1.87
Afaics only gcj-4.4 seems to be too young for the migration to testing.
Matthias
--
To UNSUBSCRIBE, email
dann frazier schrieb:
On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote:
On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes l...@debian.org wrote:
* Has progress been made regarding proper java support?
What is considered proper java support? GCJ?
Dave, have you tinkered with GCJ
Planning a gcc-4.4 upload for unstable for next week. It's not a transition (not
changing any GCC defaults), but is likely to delay transitions of other packages
due to new symbols in the various GCC runtime libraries. For now I'm not aware
of any regressions in the runtime libraries, however
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
-
severity 382686 important
tag 382686 + wontfix
thanks
these are binaries, and we are not allowed to ship those in modified form.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Andreas Tille schrieb:
Hi,
as you can see icu4j is now accepted and available for unstable. There
was some discussion which version might be best for the final goal to
package eclipse. I'm waiting for input of people who tested version
4.x.
independent of the version the osgi meta
Harald Krammer schrieb:
Hello Pantelis,
Pantelis Koukousoulas schrieb:
On Wed, Dec 31, 2008 at 4:28 PM, Harald Krammer harald.kram...@hkr.at
wrote:
[..]
Hello,
I would like to deploy a customized Eclipse development environment on
Debian Etch/Lenny.
Excellent!
We have already started
FYI, this was announced on debian-java earlier, but not the final agenda.
Matthias
---BeginMessage---
Hi all,
In less than 2 weeks our little big event will take place!
The program for our libre java meeting at Fosdem has been finalized.
There are posters with a summary of the talks to print
I filed bug reports for packages building with openjdk-6 or cacao-oj6,
producing java bytecode for version 50, and which still depend on
java-runtime5, or earlier (attached at the end).
For lenny+1, when using openjdk/cacao as the default, there will be a
lot more of these mismatches (I fixed
Mark Wielaard writes:
Hi Matthias,
On Tue, 2008-10-28 at 09:25 +0100, Matthias Klose wrote:
I filed bug reports for packages building with openjdk-6 or cacao-oj6,
producing java bytecode for version 50, and which still depend on
java-runtime5, or earlier (attached at the end
Riku Voipio schrieb:
Also I notice the packages are built with ecj using the slowish gij
interpreter. perhaps the package build could be made faster by using
gcj precompiled ecj-gcj package?
unfortunately this doesn't help; java-gcj-compat-dev already depends on ecj-gcj.
--
To UNSUBSCRIBE,
[sorry for not replying earler. please CC the package maintainer address, I
don't read debian-java
on a daily basis]
Florian Weimer schrieb:
Here are the results of building some OpenJDK packages on the security
buildd infrastructure (with the test suites disabled).
thanks for doing this.
Hi,
I would like to upload an updated cacao pre 0.99.4, builing a cacao-source
package which can be used
as a b-d for cacao-oj6. this should go unstable, so that the buildds can build
cacao-oj6. cacao is
not in testing, so this should not make things worse in unstable.
Matthias
--
To
Florian Weimer writes:
the openjdk-6 package runs the testsuite. if the security team prefers
shorter build times, then the testuite can be disabled in security
uploads.
Uhm, okay.
I didn't change this in the -2 upload.
the testsuite is not run in the cacao-oj6 package.
And build
Florian Weimer writes:
* Luk Claes:
Matthias Klose wrote:
proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including
Bastian Blank writes:
On Sun, Aug 24, 2008 at 09:43:38PM +0200, Florian Weimer wrote:
A security update for the OpenJDK 6 source base will require more than
60 hours of armel build time, and more than two weeks[1] on sparc for
openjdk-6 alone (don't know cocoa-oj6 yet).
The fastjar
proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including a JIT) is a much faster JVM on the
architectures where it does build
Unfortunately there is a lot of packages with build dependencies on
openjdk-6-jdk directly, which is a bit unfortunate. Most likely all
packages build depending on openjdk-6-jdk should have RC bug reports
because they may contain 1.6 bytecode. The following should be checked
for the release:
-
currently the -headless packages are not installable without having
the complete -jre packages installed on the system. the reason for
this is a dependency on the complete -jre packages in packages which
are dependencies of the -headless packages. The fix is to include an
alternative dependency on
the openjdk-6 6b11-4 should build on m68k. It may take a few weeks,
but I currently don't see any issue with it. If you do so, please keep
the build tree, so that the testsuite can be run, after the build
finishes (taking some more weeks to finish).
thanks, Matthias
--
To UNSUBSCRIBE, email to
So, we are late with OpenJDK for lenny. I still think lenny would
benefit from having OpenJDK. I'm proposing the following steps,
realizing that not all of them probably can be realized.
- The current 6b11-2 package is not yet ready for migration. We will
need a -3 upload which properly will
Eric Lavarde writes:
Hi,
I noticed that FreeMind works with OpenJDK 6 (as present in Ubuntu
8.04). Is this package supposed to come to Debian, and will it be in
main, contrib or non-free?
please see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=138
plus the thread starting at
Thomas Viehmann schrieb:
Hi,
Matthias Klose wrote:
thanks for looking into this. after the second try to upload and 10
days in the
NEW queue the review is a bit terse.
Up to now I found:
- The debian/copyright file seems to miss a lot of
copyright notices (e.g. of Red Hat, Maxwell
files.
Matthias Klose wrote:
- The debian/copyright file seems to miss a lot of
copyright notices (e.g. of Red Hat, Maxwell, ASF,
I stopped after finding four). This is the main
reject reason.
Of course, the ASF copyright is included in debian/copyright, shame on me.
Thanks Matthias
Package: postgresql-pljava
Version: 1.4.0-1
Severity: important
postgresql-8.3-pljava-gcj currently directly depends on a specific
version of libgcj, which is unneeded, and doesn't allow the bindings
to work with another jvm. The upstream should be built without setting
USE_GCJ, but by setting
Thomas Viehmann writes:
Hi Matthias,
in addition to the list of arch packages built from sources
declaring build-depends on binaries of java-gcj-compat, there
also is libplplot9-java declaring a depends.
Either this needs a good plan or I'm missing something.
no, you don't miss anything.
Thomas Viehmann schrieb:
Hi,
I'm afraid that openjdk-6 still needs some work:
thanks for looking into this. after the second try to upload and 10 days in the
NEW queue the review is a bit terse.
Up to now I found:
- The debian/copyright file seems to miss a lot of
copyright notices
Petter Reinholdtsen writes:
[Michael Koch]
The question is how reliable can this be? Its probably better to
just remove the package to signal the user that he needs to
reconfigure something instead of silently updating to some dummy
package and let him wonder why something broke now
IMO classpath-tools and free-java-sdk should be removed as well.
Thomas Viehmann writes:
Working... done.
Will remove the following packages from unstable:
libsablevm-classlib1-java | 1.13-2 | all
libsablevm-native1 | 1.13-2 | alpha, amd64, arm, armel, hppa, hurd-i386,
i386, ia64,
reassign 473284 ftp.debian.org
thanks
no, this package needs to be removed.
Gregory B. Prokopski writes:
Package: wnpp
Severity: normal
Hi,
This package needs a new maintainer,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
reassign 473289 ftp.debian.org
thanks
this should be removed instead. These tools are now up to date in the
icepick package.
Gregory B. Prokopski writes:
Package: wnpp
Severity: normal
Hi,
This package needs a new maintainer,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Joerg Jaspert writes:
Hi Maintainer,
rejected, lots of
E: default-jdk: no-copyright-file
E: default-jdk: debian-changelog-file-missing-or-wrong-name
noted.
Additionally you might want to listen/talk to others in the java team, which
have concerns about the package, just asking me about
Florian Weimer writes:
This does not work in a pristine build environment (such as one set up
by pbuilder) because the DLJ has to be accepted, which can't work in a
non-interactive environment.
How do you cope with that?
Preseed the debconf value.
--
To UNSUBSCRIBE, email to [EMAIL
Vincent Fourmond writes:
Hello Eric,
Eric Lavarde wrote:
I don't see the advantage of this approach over well defined virtual
packages, which I notice you seem anyway to implicitly expect
(java5-runtime, java5-sdk, etc...).
Can you perhaps elaborate a bit on this?
Autobuilders
Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.
- on arm, the bytecode compiler (ecj) doesn't produce correct code.
there is currently a workaround to build the package on arm using
byte-compiled code built on another architecture. Aurelian has
Eric Lavarde writes:
Hi everybody,
thanks for your answers, it looks like we don't have yet a consensus.
Let me try to suggest one.
POINT 1:
I would suggest to modify the Java Policy along these lines:
- the specific java runtimes listed before java(2)-runtime are the ones
tested by
Andrew Vaughan writes:
If you are going to rework the virtual packages, please consider adding
-nox packages so that java{,5}-runtime can depend the appropriate X windows
packages, and server apps that don't need X windows can depend on
java{,5}-runtime-nox.
see java-gcj-compat-headless,
Michael Koch writes:
On Sat, Oct 27, 2007 at 10:24:56PM +0200, Eric Lavarde wrote:
Package: java-common
Version: 0.26
Severity: wishlist
Hello,
in section 2.4 Java libraries it should be specified that packages
containing such libraries should belong to the 'libs' section and
Eric Lavarde writes:
Hi,
number of binary packages is relatively easy if it doesn't need to be
precise:
$ aptitude -F '%20p %13s' search '~Djava' | wc -l
419
(all packages depending on packages containing java in their name; a
quick browsing through it tells me that it's a rather
reassign 432541 eclipse-cdt
clone 432541 -1
reassign -1 gcj-4.3
thanks
eclipse-cdt still FTBFS, so keeping a duplicate there.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Andrew Haley schrieb:
Thomas Girard writes:
It built successfully in June[2], and started to fail building in July[3].
Ping Doko: what did you change in this time window?
On July 18:
gcc-4.1 (4.1.2-14) unstable; urgency=low
* Update to SVN 20070718.
* Update boehm-gc, libjava from
Matthias Klose writes:
IcedTea is a temporary fork of OpenJDK which allows building with a free
toolchain and adding/replacing code which is not yet available under a free
license. First deb Packages for amd64 and i386 are available at
deb http://people.ubuntu.com/~doko/ubuntu/ gutsy
peter green schrieb:
well, then its cheaper to add it.
I've attatched a new debian/control with the build-deps fixed up to
allow for building on sid.
fixed.
well, this is wrong, you are lacking the correct libraries. see
linux32(1) for
the personality thing.
I've attatched a new
peter green schrieb:
IcedTea is a temporary fork of OpenJDK which allows building with a free
toolchain and adding/replacing code which is not yet available under a
free
license. First deb Packages for amd64 and i386 are available at
deb http://people.ubuntu.com/~doko/ubuntu/
peter green schrieb:
Matthias Klose wrote:
ok, except wget should not be part of the b-d's, if the zip file
already exists.
The configure script checks for it and errors if it is not there.
well, then its cheaper to add it.
did you set the 32bit personality before entering the chroot
IcedTea is a temporary fork of OpenJDK which allows building with a free
toolchain and adding/replacing code which is not yet available under a free
license. First deb Packages for amd64 and i386 are available at
deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/
deb-src
Andrew Haley writes:
Marcus Better writes:
I have recently had problems building Java packages. The build would just
eat memory, and occasionally show things like:
GC Warning: Repeated allocation of very large block (appr. size 524288000):
May lead to memory leak and poor
[EMAIL PROTECTED] writes:
I think it would be better to just leave the version as is and accept
that multiple version sit around on the file system. They don' cause
any harm anyway.
they do. Do you volunteer to provide security upgrades for two years
for 10 versions of the same library?
Please could you consider uploading the current gnome-java bindings
(including the vte bindings) to unstable? You can get the current
versions from Ubuntu feisty. I won't have the time to upload these
versions myself.
Thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Paul Cager writes:
I am updating the BCEL library to the new upstream version. The old
version installed the Javadocs into:
/usr/share/doc/$package/doc/api
Daniel Baumann queried this last night on IRC, and it seems that other
(newer) packages (e.g. libxalan2-java-doc) install into
Steve Langasek writes:
On Tue, Dec 19, 2006 at 02:16:54AM -0800, Peter Ronnquist wrote:
It seems like eclipse will not be part of the etch release. Is this
a mistake?
No, it is not; it's a direct consequence of the eclipse maintainers not
having a releasable package at the appropriate
Marcus Better writes:
Andrew Haley wrote:
It's a good idea to remove generated javadoc and jar files and classes.
Very much so. Unless you build from source, you have no way to know
that the binaries correspond to that source code. You can't even
guarantee that you're not violating
Marcus Better writes:
Matthias Klose wrote:
Marcus Better writes:
instance we ship a lot of packages that build with Maven, but since we
don't have Maven in Debian, we use the included, pre-generated, Ant build
file instead. What should we do about those?
if these packages
Andrew Haley writes:
Matthias Klose writes:
Arnaud Vandyck writes:
Hi debian-java team,
I'd like us to write a common position statement about the jdk under
the gpl. I think these points should be mentioned:
o This is really a good thing for us because it is now
Ola Lundqvist writes:
-rw-r--r-- root/root 77508 2006-11-16 20:38 ./usr/include/jvmti.h
-rw-r--r-- root/root 68996 2006-11-16 20:38 ./usr/include/jni.h
drwxr-xr-x root/root 0 2006-11-16 20:38 ./usr/include/linux/
-rw-r--r-- root/root 1780 2006-11-16 20:38
Arnaud Vandyck writes:
Hi debian-java team,
I'd like us to write a common position statement about the jdk under
the gpl. I think these points should be mentioned:
o This is really a good thing for us because it is now really the GPL
(+Classpath exception), not a MPL like license;
o
Ola Lundqvist writes:
Hi
On Thu, Nov 16, 2006 at 11:22:37PM +0100, Matthias Klose wrote:
Ola Lundqvist writes:
-rw-r--r-- root/root 77508 2006-11-16 20:38 ./usr/include/jvmti.h
-rw-r--r-- root/root 68996 2006-11-16 20:38 ./usr/include/jni.h
drwxr-xr-x root/root 0
Daniel Jacobowitz writes:
On Thu, Nov 09, 2006 at 07:59:20PM +0100, Matthias Klose wrote:
Riku Voipio writes:
tags 387875 +patch
thanks
Verified that gcj-4.1 builds with this patch, and with patched version
ecj-bootstrap build fine as well.
just to clarify, could you verify
Andrew Haley writes:
Steve Langasek writes:
On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
Please consider moving the following packages to testing:
- arm: debian only port, not yet submitted to upstream; runtime is
currently non-functional, testsuite shows
Steve Langasek writes:
so in the absence of any movement in this area, I still need to
know what Debian is going to do with gcj on ARM for the upcoming etch
release.
in the worst case, remove the binaries built from gcj-4.1,
ecj-bootstrap-gcj. How many build-dependencies will be broken?
Steve Langasek writes:
On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
Please consider moving the following packages to testing:
gcj-4.1
I'm wondering whether the build-dependencies of gcj-4.1 are really accurate.
Is it really the case that gcj-4.1 will build
Blackwell writes:
David Herron wrote:
An off the top of my head guess would be - do you have GNOME installed?
Reasoning ... GtkToolkit refers to GNOME and would be using the GNOME
widgets as peers in the same manner the Motif widgets were formerly used.
please install the
Petter Reinholdtsen writes:
The most important feature is java applet support. Some of the
important test cases are listed on
URL:http://wiki.debian.org/DebianEdu/JavaInDebianEdu. Last time I
tested, few of them were working properly in Etch with gcjappletviewer. :(
apparently before
Steve Langasek writes:
On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote:
Steve Langasek writes:
On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
Please consider moving the following packages to testing:
gcj-4.1
I'm wondering whether
[didn't see this email reaching the lists, sending it again]
Please consider moving the following packages to testing:
gcj-4.1
java-gcj-compat
gcc-defaults
ecj-bootstrap
gjdoc
The packages don't show regressions compared to the versions currently
in
Wookey writes:
As mentioned below - the debian arm java situation is currently not
good. We would very much welcome any java types who could help us fix
and/or understand the problems in various java packages. Do please
spend a bit of time this weekend if you can on #debian-arm or
Joost Kraaijeveld writes:
Hi,
Can anyone tell if JNI_CreateJavaVM available in libgjc7-0 4.1.1-13
AMD64 as it seems to be missing from my installation? If not, is it
available somewhere els?
/usr/lib/gcj-4.1/libjvm.so
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
M. If the gjc team changed it's packaging in all architectures and
pljava is depending on an upstream package it might be wiser to change
pljava and file the report on the plajava package
Yes, it seems you're right. Too bad that I already filed a bug.
So it should be reassigned
Marcus Better writes:
Hello,
the pkg-jboss project needs DFSG-free versions of Sun's JavaMail and Java
Activation Framework libraries. Can anyone tell me whether the GNU versions
(already in Debian) will work out of the box?
what do you mean by out of the box? If they don't work, please
Tom Marble writes:
Juergen Kreileder wrote:
Tom Marble wrote:
Current Debian Java Policy [1] in section Chapter 2.1: Virtual Machines
stipulates If a virtual machine supports native code, it must include
the
directory /usr/lib/jni in its search path for these dynamic libraries.
Tom Marble writes:
Jeroen van Wolffelaar wrote:
Currently, there is update-java-alternatives in java-common to manage
the various java commands and how they refer to which implementation.
People can however ignore it and update-alternatives themselves, things
can get out-of-sync, and how
gcj-4.1 in experimental is not just about gcjwebplugin; it contains a
backport of a classpath-0.92 prerelease and gcj from the current
trunk. it's this upgrade which makes gcj interesting for etch. If we
do want to include, it has to be tested with packages currently
depending on it (packages
Jeroen van Wolffelaar writes:
and how to set priorities is unclear and not easy to decide on.
IIRC that we decided on the priorities. See
http://lists.debian.org/debian-java/2006/05/threads.html
In the current Debian Java policy, java libraries are required to
properly document how to modify
Mark Wielaard writes:
Make sure that it is removed from
libjava/java/text/DateFormat.java and that there is a new file
libjava/classpath/java/text/DateFormat.java
Similar for SimpleDateFormat.java.
that was the hint needed. I had some empty .java files still laying
around :-/
Test results
just drop libgcj6-dev, gcj depends on the correct version.
Rafael Laboissiere writes:
[Please, Cc: to me since I am not subscribed to debian-java.]
The autobuilders are failing to build the plplot package because the
build-dependencies on java are not correct. I have:
Build-Depends:
Martin Kuball writes:
Hi!
Why does libswt3.1-gtk-java depend on mozill-browser? Would a
dependency on a generic browser suffice? I can't believe that I have
to install yet another browser just to run swt apps.
please read the eclipse changelog, if you cannot believe it.
--
To
Martin Kuball writes:
Am Sunday, 28. May 2006 15:36 schrieb Matthias Klose:
Martin Kuball writes:
Hi!
Why does libswt3.1-gtk-java depend on mozill-browser? Would a
dependency on a generic browser suffice? I can't believe that I
have to install yet another browser just to run swt
Blackwell writes:
Arnaud Vandyck wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Blackwell a écrit :
[...]
Arnaud, I realize that you folks are working on Debian for free. But
that for me is not an acceptable excuse for any kind of decision,
because what you are doing
now that non-free java jre's and jdk's are available in non-free, we
should get some agreement about the priorities for the different tools
and environments. some proposals:
- things in main have higher priorities than things in contrib
and non-free.
- an alternative installed as a set of
In view of the proposed policy amendments, would it make sense to have CDBS'
ant class default to java-gcj-compat-dev, that is, set JAVA_HOME
= /usr/lib/jvm/java-gcj by default? Of course packages can still override
this as before, but it would make things easier for new packages and
applications like
openoffice or eclipse. The fix is upstream and will be in 4.1, so
please be patient.
Matthias
PS: please don't CC control on replies.
Sanyi
2005/10/13, Matthias Klose [EMAIL PROTECTED]:
forwarded 333733 http://gcc.gnu.org/PR23503
tags 333733 + upstream
tags 333733
Shaun Jackman writes:
2005/9/28, Nathanael Nerode [EMAIL PROTECTED]:
These excuses seem to be circular between swingwt and swt-gtk.
Classic hint situation. They both have to go in together; the
excuses are showing that if you move only one in, it breaks the
other. Send a message to
See #176629: gij-3.2: package incorrctly provides java1-runtime. Is
this a somewhat valid report? which runtime implementations provide
the complete runtime?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Updated Debian packages for the 1.4 runtime and sdk can be found at
http://cs.tu-berlin.de/~doko/tmp/. I know that Stephen did prepare
some packages, but did never upload them.
Juergen, is there a chance to move them to the blackdown archives?
Thanks, Matthias
--
To UNSUBSCRIBE, email to
Is there any reason to keep these packages? They are replaced by the
corresponding packages built from the gcc-3.3 source package.
Matthias
At http://master.debian.org/~doko/gcc you find new experimental
gcj/libgcj packages. This can be installed in parallel with the
gcX-2.95 packages from unstable, so it should be easy to play with the
experimental packages. With gcj-3.0 final I plan to remove the
gcj-2.95 and libgcj0 packages. Happy
FAQ 5.1.2 potato
The kit is named ibm-jdk1.1-installer. The paragraph should be
rewritten. It's not alpha anymore, it's not at this location anymore.
It's part of potato for now. I would be interested how the license
prohibits the installation by an installer
The other comments regarding
Fixed in gcj-2.95.2-4.
Stephane Bortzmeyer writes:
On Friday 17 December 1999, at 12 h 3, the keyboard of Matthias Klose
[EMAIL PROTECTED] wrote:
thought I fixed this. I will make a new upload this weekend.
fix: in debian/rules.patch don't add gcj-backport to the list
... thought I fixed this. I will make a new upload this weekend.
fix: in debian/rules.patch don't add gcj-backport to the list of patches.
201 - 300 of 302 matches
Mail list logo
