gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Vandyck <>
Subject Re: Debian Gump
Date Sun, 07 Aug 2005 12:38:57 GMT

Beginning of the thread:

Mark Wielaard wrote:
> Hi,
> On Sat, 2005-08-06 at 17:24 +0200, Arnaud Vandyck wrote:
>>>I have CCed Leo Simons which has been helping a lot with the kaffe setup
>>>and gave a presentation on Gump at Fosdem. Hopefully he has some raw
>>>estimates on resource numbers.
>>I remember the great presentation ;-)
> And just for reference, here is a pointer to Leo's presentations:
>>>General setup instructions are at:
>>I'll read it when I'll have some time but I'll wait for an estimation
>>about the resources needed by gump.
>>>We also have to come up with a free workspace for gump. The default has
>>>some non-free binary dependencies.
>>Which ones?
> Unfortunately the link on that page above describing the packages is
> dead:
> And so is the source code link on that page.
> But the "blue" packages at the following page are not build.
> Not all of them are non-free though.

jaxp: we have gnujaxp, don't we?
antlr is in debian main (free)
javamail: we have gnumail etc...

I think we have some packages that could replace those non-free or that
are free.

>>The problem I see here is: how to upload a package that does not build!
>>I mean at the moment, we build packages with kaffe when it's possible,
>>not when it's not! If it's not possible to build the package with kaffe,
>>(or with another free runtime/compiler), we have to build it with
>>non-free JDK in order to upload it. Maybe we have to try to pass some
>>'magic' envvar to tell the package to build with kaffe and not with
>>non-free JDK. In that way, we'll have interesting results (but not if we
>>upload only packages that we already know can be build) but it's not a
>>trivial job and we'll have some packages to change!
> The number of those packages is dropping fast. The main problem will be
> to "pin down" the free runtime/compiler combination for each package
> that the packager maintainer feels most comfortable with. But in general
> the runtime will be gij/gcj-native or kaffe since those are really the
> only options available on all Debian architectures. On the compiler
> side, when not using gcj, the choice is between kjc, jikes, and ecj. But
> the main reason for things not building is the class libraries, and
> those are luckily shared between all runtime, compilers and tools these
> days.
> Which packages that cannot be build are you thinking of in general here?

I'm thinking about argouml, or some other packages that are stuck in
contrib because of javax.swing.html.* etc. If those packages cannot be
build, we can't upload them to the pool so we can't integrate them in gump.

[Just a note for the gump users: we wanna use gump to test the runtimes
and compilers, not to tests the other java softs ;-)]

>>One thing that could be interesting is to run the unit tests. I think
>>unit tests should not be blockers for our packages, but gump could log
>>them and give us good informations about the real state of a package.
> Gump does that already. If the unit tests fail then the package is
> flagged as broken (meaning also all packages that depend on it are not
> build).

That was not was I was thinking about: if tests do not pass, the package
must be uploaded with a note that it can't be run with free-JVM.


 : :' :rnaud
 `. `'
Java Trap:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message