[pkg-eucalyptus-maintainers] [Debian] Re: Possible FTBS?

[Rudy Godoy Guillén]

Hello Graziano,

2011/8/16 graziano obertelli <graziano at eucalyptus.com>

> Hello Rudy,
>
> On 08/15/2011 10:20 AM, Rudy Godoy Guillén wrote:
> > Hello,
> >
> > On Mon, Aug 15, 2011 at 3:19 AM, graziano obertelli
> > <graziano at eucalyptus.com <mailto:graziano at eucalyptus.com>> wrote:
> >
> >     Rudy, Charles,
> >
> >     On 08/14/2011 06:30 AM, Charles Plessy wrote:
> >     > Le Wed, Aug 10, 2011 at 02:06:10PM -0500, Rudy Godoy Guillén a
> écrit :
> >     >>
> >     >> The problem is that the existing packaging patches upstream
> Makefile
> >     >> (gatherlog/Makefile and others). The patch removes the following
> >     lines
> >     >> and other (see at the end of the message):
> >     >>
> >     >> -       sh $(WSDL2C) -uri $(GLWSDL) -g -d adb -u -uw -f -o
> >     generated | grep
> >     >> -v 'the classpath'
> >     >>
> >     >> The build later expects a set of files in the
> 'gatherlog/generated'
> >     >> directory, in order to add some bits (tools/add_marshalling.pl
> >     <http://add_marshalling.pl>), that are
> >     >> not present, so the whole build fails.
> >     >>
> >     >> I've identified the patches comming from
> >     >> debian/patches/temporary_lintian_fixes.patch but also from the
> >     >> debian/rules' setup-lib target.
> >     >
> >     > Dear Rudy,
> >     >
> >     > if you can not find the origin of the patch (no meaningful commit
> >     message ?),
> >     > and if Eucalyptus works without, perhaps it would be better to
> >     remove it.
> >     > Do you have one extra lintian tag after removal ?
> >     >
> >     > Have a nice day,
> >     >
> >
> >     I'm not fully sure what the patch is, but it seems that it prevent
> the
> >     creation of the stubs from the wsdl. I wonder if this was done to
> >     prevent the dependency at build time on $WSDL2C which is a java
> program.
> >     This would work only if the stubs are checked in the source tree you
> are
> >     using.
> >
> >
> > Thank you for the feedback. Yes, the patch is to prevent the stubs being
> > generated and it's related to dependency on the AXIS2 Java package
> > (which is not present in Debian, instead the C version is). I've managed
> > to pass that point by exporting the AXIS2_HOME env variable from my
> > .zshrc so it's used by the subshell call (I guess that's the real
> > problem here -my workaround doesn't resolve in the long-term-), and the
> > build goes fine, stubs are generated and so.
>
> Ok.
>
> > However, I'm stuck with a build errors from Java's source code coming
> > from groovy I yet have to debug. I'll post some news by the end of the
> > day (for my timezone).
> >
> >
> /home/rudy/debian/devel/soc-2011/eucalyptus/eucalyptus-2.0.3-src-offline/clc/modules/msgs/src/main/java/org/apache/tools/ant/util/DateUtils.java
> > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> > failed:
> > Compile error during compilation with javac.
> >
> /home/rudy/debian/devel/soc-2011/eucalyptus/eucalyptus-2.0.3-src-offline/clc/modules/msgs/src/main/java/com/eucalyptus/bootstrap/ServiceJarDiscovery.java:33:
> > cannot find symbol
> > symbol  : method newArrayListMultimap()
> > location: class com.google.common.collect.Multimaps
> >   private static Multimap<Class, String>        classList =
> > Multimaps.newArrayListMultimap( );
>
> I seem to recall issues with the different version of groovy. Which
> version do you have installed? I'm not very versed with groovy and java:
> I will try to ask around the day after tomorrow (I will be out of office
> tomorrow).
>
>
I've managed to isolate the problem. The error is related to the jar files
on clc/lib. The Debian build uses debian/build-jars to make symlinks to
installed Java libs, however the "normal" upstream ant build downloads from
eucalyptus and builds them correctly.

Currently I've the following version from sid:
- groovy 1.8.1

cloud-lib.tar.gz ships:
- groovy 1.7.0

The packaging build error, at the end, is related to Jar Index conflict.
According it's definition there's a difference between what is expected and
what is in the INDEX.LIST for that class in the jar file. I'm about to
identify if this is related to the groovy version or to other class.

Best regards,
Rudy

/home/rudy/debian/devel/soc-2011/eucalyptus/pkg-eucalyptus/build-area/eucalyptus-2.0.3/clc/modules/msgs/src/main/java/\
org/apache/tools/ant/util/DateUtils.java
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
General error during conversion: Invalid index

sun.misc.InvalidJarIndexException: Invalid index
        at
sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:870)
        at
sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:779)
        at sun.misc.URLClassPath.getResource(URLClassPath.java:185)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:209)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
        at
groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:673)
        at
groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:540)
        at
org.codehaus.groovy.control.ResolveVisitor.resolveToClass(ResolveVisitor.java:663)
        at
org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:268)
        at
org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:446)
        at
org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:268)
        at
org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1128)


-- 
Rudy Godoy
http://stone-head.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/attachments/20110817/869d8fd9/attachment.html>