"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes:
> W liÅcie z czw, 12-02-2004, godz. 14:50, Adam Majer pisze:
>> I think I'm going to reintroduce jikes-gij as part of jikes
>> source. It might be the lesser of two evils. I think that
>> adding jikes-gij to gcc is not the best idea :) And jikes
W liście z czw, 12-02-2004, godz. 14:50, Adam Majer pisze:
> I think I'm going to reintroduce jikes-gij as part of jikes
> source. It might be the lesser of two evils. I think that
> adding jikes-gij to gcc is not the best idea :) And jikes-gij
> is not going to slow down jikes anyway since gcc is
Hi,
I think I'm going to reintroduce jikes-gij as part of jikes
source. It might be the lesser of two evils. I think that
adding jikes-gij to gcc is not the best idea :) And jikes-gij
is not going to slow down jikes anyway since gcc is priority
important and has an entire team working on it.
- A
classpath 0.07-2 has been accepted.
Please let me know if there any problems with it or jikes-classpath
John Leuner
On Wed, 2004-01-21 at 00:33, Ben Burton wrote:
> > Would it work if, say, classpath built a new package
> > 'jikes-with-classpath' (whatever the name, but a new one), which
> >
On Fri, Jan 23, 2004 at 03:44:21PM -0500, Andrew Pimlott wrote:
> On Fri, Jan 23, 2004 at 12:15:27AM -0600, Adam Majer wrote:
> > On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> > > Irrespective of the testing issue, it seems obvious that just as the
> > > jikes source package is
On Fri, Jan 23, 2004 at 12:15:27AM -0600, Adam Majer wrote:
> On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> > Irrespective of the testing issue, it seems obvious that just as the
> > jikes source package is the wrong place for these wrappers (why
> > should the compiler know abo
> 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
1. People installing a VM do not need to install jikes so first one is out.
I agree with that, as I said before.
2. The entire point of putting wrappers in the source package of another
package (like a compiler, or JVM), is to not bloat the /pool with
stupid little 20 byte sources.
True, b
On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> > These JVMs are encouraged and free to move these one-file wrappers to
> > their own packages (which in turn will probably Depend: on jikes or
> > make it Reco
On Wed, Jan 21, 2004 at 01:46:40PM +0100, Daniel Bonniot wrote:
> Stefan Gybas wrote:
>
> >Daniel Bonniot wrote:
> >
> >>One solution to this (which I found at
> >>http://www.mail-archive.com/[EMAIL PROTECTED]/msg10605.html)
> >>would be to temporily make new (empty) versions of the jikes-* pack
Stefan Gybas wrote:
Daniel Bonniot wrote:
One solution to this (which I found at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg10605.html)
would be to temporily make new (empty) versions of the jikes-*
packages with priority extra, and that only depend on the new
jikes-with-* packages.
T
Daniel Bonniot wrote:
One solution to this (which I found at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg10605.html)
would be to temporily make new (empty) versions of the jikes-* packages
with priority extra, and that only depend on the new jikes-with-*
packages.
This would require a new
> 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
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 wouldn
> 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
On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> These JVMs are encouraged and free to move these one-file wrappers to
> their own packages (which in turn will probably Depend: on jikes or
> make it Recommend: and make wrappers fail gracefully or sth. like that).
>
> I seek
Daniel Bonniot wrote:
But jikes-kaffe also needs to depend on jikes, while kaffe itself does not.
I think a suggestion would be enough. The wrapper can be changed to
print an error message if jikes is not installed. And nobody is using
the /usr/bin/javac alternatives anyway, right?
Stefan
--
T
If they are in separate packages which are then built by the JVM
source packages, yes. However, I think they should just be in the
"main package", e.g. directly in kaffe. jikes-kaffe depends on kaffe
anyway so a separate package does not make a lot of sense IMHO.
But jikes-kaffe also needs to d
On Tue, Jan 20, 2004 at 02:42:53PM +0100, Daniel Bonniot wrote:
> Epochs are a pain, if only because the look ugly and because they can
> never be gotten rid of. Is this the only solution?
>
> Would it work if, say, classpath built a new package
> 'jikes-with-classpath' (whatever the name, but a
Grzegorz B. Prokopski wrote:
Speaking of maintenace. Currently jikes is at version 1.18-6. This means
that currently these wrappers are also at version 1.18-6. Once they're
moved to respective JVMs - they'll have the same versions as each JVM.
If they are in separate packages which are then built
Hi,
Thus I'll upload a new version of jikes in a few hours without any
wrappers.
Great. Looking forward to a new jikes in testing.
Everyone should make their packages either epoch 2
(ie. version 2:x.x.x) or make sure they are later or equal to
1:1.19 or so. Anything else would mess up the upgra
W liście z pon, 19-01-2004, godz. 21:44, Adam Majer pisze:
> I'm not sure how long it will take these wrappers to dissapear from
> sid by themselves (ie. not build from jikes source). I'm guessing
> a few days at least. Someone could of course file bugs against
> ftp-master to get them removed, bu
On Mon, Jan 19, 2004 at 11:51:50PM +0100, Arnaud Vandyck wrote:
> Adam Majer <[EMAIL PROTECTED]> writes:
>
> > It doesn't really matter to me. I just need everyone to agree on this
> > so that the wrappers don't simply dissapear. Grzegorz (SableVM) surely
> > will agree. gij will probably have lit
Adam Majer <[EMAIL PROTECTED]> writes:
> It doesn't really matter to me. I just need everyone to agree on this
> so that the wrappers don't simply dissapear. Grzegorz (SableVM) surely
> will agree. gij will probably have little problem with this either.
>
> I just need a yes from both Ean (Kaffe)
> 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
>
W liście z pon, 19-01-2004, godz. 10:34, John Leuner pisze:
> > I just need a yes from both Ean (Kaffe) and John (Classpath). I can upload
> > a new version of jikes tomorrow if everyone agrees.
>
> I can add the jikes-classpath script to the classpath package.
good!
> It wasn't clear from the d
> I just need a yes from both Ean (Kaffe) and John (Classpath). I can upload
> a new version of jikes tomorrow if everyone agrees.
I can add the jikes-classpath script to the classpath package.
It wasn't clear from the discussions exactly what version changes are
required
What versioning changes
Hi Adam,
Adam Majer wrote:
I guess if we can't work something out, we'll just have to fix kaffe :)
I guess the simplest approach in this direction is to ask developers on
those architectures to help with the FTBFS, in case that they are
interested in using kaffe on those platforms.
cheers,
dal
W liście z pon, 19-01-2004, godz. 02:10, Adam Majer pisze:
> On Sun, Jan 18, 2004 at 09:49:44PM -0500, Grzegorz B. Prokopski wrote:
> > W li?cie z nie, 18-01-2004, godz. 19:41, Adam Majer pisze:
> > > PS. Furthermore, since these wrappers are NOT and should not be dependent
> > > on version of th
On Sun, Jan 18, 2004 at 09:49:44PM -0500, Grzegorz B. Prokopski wrote:
> W li?cie z nie, 18-01-2004, godz. 19:41, Adam Majer pisze:
> > PS. Furthermore, since these wrappers are NOT and should not be dependent
> > on version of the JVM (or kaffe), they should be maintained such that
> > they work
W liście z nie, 18-01-2004, godz. 19:41, Adam Majer pisze:
> PS. Furthermore, since these wrappers are NOT and should not be dependent
> on version of the JVM (or kaffe), they should be maintained such that
> they work with ALL the versions of the JVM. This should be simple enough :)
Speaking of
On Sun, Jan 18, 2004 at 11:04:55PM +0100, Arnaud Vandyck wrote:
> Adam Majer <[EMAIL PROTECTED]> writes:
> > Jikes only needs *any* version to be in testing. A given package has
> > to be removed from testing for the current problems to occur.
> > Hopefully, kaffe will get into testing by the middl
Adam Majer <[EMAIL PROTECTED]> writes:
> On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
>> [*] This is completly irrelevant that jikes is currently held by
>> Kaffe. Tomorrow it may be held by SableVM, and in a week by Classpath
>> or GIJ.
>
> Jikes only needs *any* version
W liście z sob, 17-01-2004, godz. 15:50, Adam Majer pisze:
> On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> > while jikes has:
> >
> > Recommends: jikes-gij | jikes-kaffe | jikes-sun | jikes-classpath |
> >jikes-sablevm
> >
> > where jikes-sun is in the contrib sect
I asked at #debian-devel and was adviced to contact debian-release.
So this is mainly for debian-release to take a look at.
W liście z sob, 17-01-2004, godz. 06:38, Mark Howard pisze:
> On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> > The problem is known, I pointed it o
On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> [*] This is completly irrelevant that jikes is currently held by
> Kaffe. Tomorrow it may be held by SableVM, and in a week by Classpath
> or GIJ.
Jikes only needs *any* version to be in testing. A given package has
to be re
Hi,
On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> The problem is known, I pointed it out here at least once. Jikes
> provides all these wrappers jikes-* for different JVMs. This makes the
> source package dependant on ALL these JVMs. The result is that if ANY
> [*] the
Hi!
Please take a look at http://qa.debian.org/developer.php?excuse=jikes
which says: "149 days old (needed 2 days)" !!!
Current unstable version is 1.18-6, but testing is still at 1.15-2 !
The problem is known, I pointed it out here at least once. Jikes
provides all these wrappers jikes-* for d
39 matches
Mail list logo
