Package: java-common
Version: 0.52
Severity: wishlist
update-java-alternatives could be enhanced with bash completion.
After typing --set it would be nice to have an auto completion
of the available alternatives.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject
* Niels Thykier:
> But what would you hope to achieve by making update-java-alternatives
> usable in postinst? What does it do that the current maintainer scripts
> cannot (or are not) do(ing) with update-alternatives?
We've got our own internal OpenJDK builds, and I noticed that
On 2011-11-07 15:39, Florian Weimer wrote:
> Why is update-java-alternatives not used in the postinst script of Java
> implementations? I guess it's because there is no way to invoke in such
> that it makes the required adjustments, and only those. Would it make
> sense to en
Why is update-java-alternatives not used in the postinst script of Java
implementations? I guess it's because there is no way to invoke in such
that it makes the required adjustments, and only those. Would it make
sense to enhance update-java-alternatives to install new alternatives,
wi
Your message dated Mon, 19 Apr 2010 07:17:12 +
with message-id
and subject line Bug#563070: fixed in java-common 0.36
has caused the Debian Bug report #563070,
regarding java-common: "update-java-alternatives --list " fails, w.
patch.
to be marked as done.
This means that you
Your message dated Mon, 12 Apr 2010 16:51:35 +0200
with message-id <4bc33377.2000...@thykier.net>
and subject line Re: [java-common] "update-java-alternatives --plugin -s
java-6-sun", fails to update iceweasel-javaplugin.so alternative
has caused the Debian Bug report #544680,
Your message dated Sun, 11 Apr 2010 13:36:03 +0200
with message-id <4bc1b423.9040...@thykier.net>
and subject line Re: java-common: update-java-alternatives "cannot find
alternative, `/usr/lib/gcj-4.1/libgcjwebplugin.so' "
has caused the Debian Bug report #409901,
regardin
Your message dated Sun, 11 Apr 2010 13:29:18 +0200
with message-id <4bc1b28e.5050...@thykier.net>
and subject line Re: java-common: update-java-alternatives fail to set
alternatives for jdk
has caused the Debian Bug report #41,
regarding java-common: update-java-alternatives fail
Package: java-common
Version: 0.30
Severity: normal
Tags: patch
# update-java-alternatives -v --jre --list java-gcj
listing java alternatives:
awk: cmd. line:1: fatal: cannot open file `/usr/lib/jvm/java-gcj.jinfo' for
reading (No such file or directory)
java-gcj /usr/lib/jvm/java-gcj
On Mon, Sep 28, 2009 at 11:32:30PM +0200, Arnout Engelen wrote:
> Package: java-common
> Version: 0.30
> Severity: normal
>
>
> update-java-alternatives lacks a manpage, making it not show up in 'man -k'
> and generally hard-to-find.
mk...@oberon:~$ cat /etc/deb
Your message dated Tue, 29 Sep 2009 06:36:09 +0200
with message-id <20090929043609.gp12...@quadriga.konqueror.de>
and subject line Re: Bug#548809: java-common: update-java-alternatives lacks a
manpage
has caused the Debian Bug report #548809,
regarding java-common: update-java-alternatives
Package: java-common
Version: 0.30
Severity: normal
update-java-alternatives lacks a manpage, making it not show up in 'man -k'
and generally hard-to-find.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (
Package: java-common
Version: 0.33
Severity: normal
--- Please enter the report below this line. ---
[12:19] ~ => sudo update-java-alternatives --plugin -s java-6-sun
burek
Using '/usr/lib/jvm/java-6-sun/jre/lib/amd64/
Package: java-common
Version: 0.27
Severity: normal
Here's the trace of running " update-java-alternatives --set java-6-sun":
No alternatives for appletviewer.
No alternatives for apt.
No alternatives for extcheck.
No alternatives for firefox-javaplugin.so.
No alternatives for
Processing commands for [EMAIL PROTECTED]:
> retitle 409302 update-java-alternatives: wrong syntax in README.alternatives
Bug#409302: update-java-alternatives is broken
Changed Bug title.
> clone 409302 -1
Bug#409302: update-java-alternatives: wrong syntax in README.alternatives
Bug
retitle 409302 update-java-alternatives: wrong syntax in README.alternatives
clone 409302 -1
reassign 409302 sun-java5
reassign -1 sun-java6
thanks
On Tuesday 06 February 2007 15:43, Steve Langasek wrote:
> On Thu, Feb 01, 2007 at 10:32:24PM +0100, Nicolas DEGAND wrote:
> > After migra
Package: java-common
Version: 0.25
Severity: important
Hi
I have multiple jdks installed, including gcj-4.1, sun-java5 (from non-free),
Sun and IBM java 1.4 (via sarge's java-package).
When I use update-java-alternatives --set java-gcj to switch to gjc, I get
...
Using `/usr/lib/jvm
that /etc/alternatives
> was still pointing to java 1.5.
> /usr/share/doc/sun-java6-bin/README.alternatives said that I should type
> (this should probably been done automagically during upgrade and I
> guess it has been designed to be this way, but it seems flawed)
> :
> update-java-al
Processing commands for [EMAIL PROTECTED]:
> severity 409302 important
Bug#409302: update-java-alternatives is broken
Severity set to `important' from `grave'
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrato
/sun-java6-bin/README.alternatives said that I should type
(this should probably been done automagically during upgrade and I
guess it has been designed to be this way, but it seems flawed)
:
update-java-alternatives --jre java-6-sun
But the script does not work (it only prints the help messages
es of the both, depending if they're meant
> > to be Runtime or Development commands?
>
> You are correct. A solution to this problem has been incorporated into
> java-common 0.25: update-java-alternatives(8)
>
> Each technology implementation defines the set of
efine only alternatives for java and javac, and
> >> everything
> >> else would be slave alternatives of the both, depending if they're meant
> >> to be Runtime or Development commands?
> >
> > You are correct. A solution to this problem has been incorporat
g if they're meant
>> to be Runtime or Development commands?
>
> You are correct. A solution to this problem has been incorporated into
> java-common 0.25: update-java-alternatives(8)
>
Thanks for the hint, I've just seen that java-common 0.25 entered testing,
so I should
On Tue, May 23, 2006 at 03:14:17PM -0400, Charles Fry wrote:
> > > 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
> > >
> > > Th
are correct. A solution to this problem has been incorporated into
java-common 0.25: update-java-alternatives(8)
Each technology implementation defines the set of runtime, development
and plugin alternatives in a file:
/usr/lib/jvm/.$jname.jinfo
Contents of /usr/lib/jvm/.java-1.5.0-sun.jinfo
ava or back.
man update-java-alternatives
Seo Sanghyeon
Michael Koch gmx.de> writes:
> We decided at FOSDEM to make GCJ then default. The rest is ok with me.
Fine for me, too.
cheers,
dalibor topic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > 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
Hi,
>> Before popcon (number of downloads), I would suggest number of
>> non-library
>> packages depending on the VM, i.e. if you install a certain VM, how many
>> applications will you be able to run with it, without having to install
>> another VM and play with JAVA_HOME etc...
>
> You are propo
> >> 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,
>
>>>- ordering of the free runtimes. can we agree on some kind of order?
>>
>> 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 (nu
On Tue, May 23, 2006 at 05:29:34PM +0200, Arnaud Vandyck wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dalibor Topic a écrit :
> > Matthias Klose cs.tu-berlin.de> writes:
> >
> >>now that non-free java jre's and jdk's are available in non-free, we
>
> Yeah! Thanks for the work!..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dalibor Topic a écrit :
> Matthias Klose cs.tu-berlin.de> writes:
>
>>now that non-free java jre's and jdk's are available in non-free, we
Yeah! Thanks for the work!..
>>should get some agreement about the priorities for the different tools
>>and e
Matthias Klose cs.tu-berlin.de> writes:
>
> 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
> an
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 alt
/usr/lib/fjsdk/bin/java-alt-setup
that will let you set pretty much all possible java alternatives.
Not at once, but at least you won't forget to change anything.
HTH
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Deb
Yes. You are right. I had forgotten that some of these combinations are
possible, and sometimes wanted.
No other solution presents itself immediately.
Tue, 31 Aug 2004 13:25:49 -0500,
Jerry Haltom <[EMAIL PROTECTED]> wrote:
> I've noticed java, javac, javap, javah, jar, jarsigner, and all the
> others, are separate alternatives. I was thinking (experiencing) that
> this make it awfully hard to change your default VM, as you have to
> change ea
I've noticed java, javac, javap, javah, jar, jarsigner, and all the
others, are separate alternatives. I was thinking (experiencing) that
this make it awfully hard to change your default VM, as you have to
change each one of these commands. You may miss one, and then, while
building something may b
39 matches
Mail list logo
