Debian Gump

Mark Wielaard mark at klomp.org
Sat Aug 6 18:39:23 UTC 2005


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.

> 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?

> 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).

Cheers,

Mark
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20050806/a5691a3f/attachment-0001.pgp


More information about the pkg-java-maintainers mailing list