Cc'ing [email protected] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
