Debian Gump

[Arnaud Vandyck]

Cc'ing general at gump.apache.org

Beginning of the thread:
http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2005-August/004438.html
http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2005-August/004440.html

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:
> http://people.apache.org/~leosimons/presentations/
> 
> 
>>>General setup instructions are at:
>>>http://gump.apache.org/gettingstarted.html
>>
>>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: http://brutus.apache.org/gump/public/packages.html
> And so is the source code link on that page.
> But the "blue" packages at the following page are not build.
> http://gump.zones.apache.org/gump/kaffe/buildLog.html
> 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.

Cheers,

-- 
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html