Bug#348649: ftbfs: "I can't find file `policy.aux'."
tags 348649 + unreproducible moreinfo thanks Hi, I just tried it on an uptodate sid and with an uptodate pbuilder and both built java-common without a problem. Can you retry and if it still fails provide more information about the system and the versions of the build-dependencies you are using during build. Thanks, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351076: ant: Java illegalAccess exception with the kaffee compiled version
severity 351076 normal thanks Hi Akos, this is not grave if it fails for one type of build file, therefore lowered severity to normal. ant is used here in almost all the package builds and no build failed because of the new upload. Frohner Akos wrote: > The example build.xml file reports the following error with 1.6.5-4, > 1.6.5-5, but worked up to 1.6.5-3 (explicitly checked with 1.6.2): Have you explicitly checked with 1.6.5-3 ? Checking with 1.6.2 does not mean it worked up to 1.6.5-3. > build.xml:3: java.lang.IllegalAccessError: tried to access field > org.apache.tools.ant.taskdefs.Concat.fileUtils from class > org.apache.tools.ant.taskdefs.Concat$TextElement > > > > > shall work > > > > > > > > > > The only difference, according to the changelog, is that from > 1.6.5-4 ant is compiled with kaffee. The difference is its compiled with ecj - it was already compiled with kaffe a longer time (just with jikes). Maybe ecj produces for this special case wrong bytecode. This needs to be investigated. I will rebuild with jikes to see what happens. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350694: velocity: FTBFS: -Dbuild.compiler=jikes without Build-Depends on jikes
tags 350694 + pending thanks Daniel Schepler wrote: > Package: velocity > Version: 1.4-3 > Severity: serious The package is ready for upload since some time. However my sponsor is currently quite busy. Will be resolved soon. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348363: Other classpath possibility
Hi, just got informed that /usr/share classpath links are prefered. You can also use: /usr/share/kaffe-common/lib/glibj.zip for the classpath. Sorry for inconvenience. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348371: libgnu-regexp-java: FTBFS due to upstream changes in the kaffe package
Package: libgnu-regexp-java Version: 1.1.4-3 Severity: serious Tags: patch Justification: no longer builds from source Hi, kaffe upstream changed quite a lot for the newest release. Therefore the used classpath is no longer valid. The attached patch against the makefile fixes the ftbfs. Regards, Wolfgang -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages libgnu-regexp-java depends on: ii blackdown-j2sdk1.3 [java2 1.3.1+02b Java(TM) 2 SDK, Standard Edition, ii gij [java1-runtime] 4:4.0.2-2 The GNU Java bytecode interpreter ii gij-4.0 [java1-runtime] 4.0.2-6The GNU Java bytecode interpreter ii jamvm [java1-runtime] 1.4.1-1virtual machine which conforms to ii kaffe-jthreads [java1-run 2:1.1.6.91-1 A green threads enabled version of ii kaffe-pthreads [java1-run 2:1.1.6.91-1 A POSIX threads enabled version of ii libgetopt-java1.0.11-1 GNU getopt - Java port ii sablevm [java1-runtime] 1.11.3-2 Free implementation of Java Virtua ii sun-j2sdk1.4 [java2-runti 1.4.2+07 Java(TM) 2 SDK, Standard Edition, ii sun-j2sdk1.5 [java2-runti 1.5.0+update02 Java(TM) 2 SDK, Standard Edition, libgnu-regexp-java recommends no packages. -- no debconf information --- debian/rules.orig 2006-01-16 17:22:55.0 +0100 +++ debian/rules2006-01-16 17:23:21.0 +0100 @@ -7,7 +7,7 @@ debian/stamp/binary/arch : debian/stamp/binary/libgnu-regexp-java -export CLASSPATH=.:/usr/share/kaffe/Klasses.jar:/usr/share/java/gnu-getopt.jar +export CLASSPATH=.:/usr/share/kaffe-common/lib/glibj.zip:/usr/share/java/gnu-getopt.jar debian/stamp/build : $(MAKE) -C src JAVAC=jikes gnu.regexp utils
Bug#348366: tightvnc-java: FTBFS due to upstream changes in the kaffe package
Package: tightvnc-java Severity: serious Tags: patch Justification: no longer builds from source Hi, kaffe upstream changed quite a lot for the newest release. Therefore the used classpath is no longer valid. The attached patch against the makefile fixes the ftbfs. Regards, Wolfgang -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) --- Makefile.orig 2006-01-16 17:13:59.0 +0100 +++ Makefile 2006-01-16 17:14:21.0 +0100 @@ -22,7 +22,7 @@ SocketFactory.java HTTPConnectSocketFactory.java \ HTTPConnectSocket.java ReloginPanel.java -OPTS = -classpath /usr/share/kaffe/Klasses.jar:/usr/share/kaffe-common/lib/rt.jar +OPTS = -classpath /usr/lib/kaffe/jre/lib/rt.jar all: $(CLASSES) $(ARCHIVE)
Bug#348363: vnc-java: FTBFS due to upstream changes in the kaffe package
Package: vnc-java Severity: serious Tags: patch Justification: no longer builds from source Hi, kaffe upstream changed quite a lot for the newest release. Therefore the used classpath is no longer valid. The attached patch against the makefile fixes the ftbfs. Regards, Wolfgang -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) --- makefile.orig 2006-01-16 16:52:01.0 +0100 +++ makefile 2006-01-16 16:53:06.0 +0100 @@ -17,7 +17,7 @@ vncCanvas.java optionsFrame.java clipboardFrame.java \ animatedMemoryImageSource.java DesCipher.java -OPTS = -classpath /usr/share/kaffe/Klasses.jar:/usr/share/kaffe-common/lib/rt.jar +OPTS = -classpath /usr/lib/kaffe/jre/lib/rt.jar all: $(CLASSES) $(ARCHIVE)
Bug#335570: java-gcj-compat: Missing dependency - renders package unusable
Package: java-gcj-compat
Version: 1.0.41-1
Severity: grave
Justification: renders package unusable
Hi,
trying /usr/lib/jvm/java-gcj/bin/java gives me:
error spawning gij
Running with strace shows that the java binary assumes an
unversioned gij binary in /usr/bin
execve("/usr/bin/gij", ["./java"], [/* 39 vars */]) = -1 ENOENT (No such
file or directory)
However java-gcj-compat only depends on gij-4.0 and not on the
/usr/bin/gij providing gij package.
Of course installing gij fixes the problem. So either the java
binary should be patched to look for /usr/bin/gij-4.0 or the
dependency should be updated to gij instead of gij-4.0
Regards,
Wolfgang
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages java-gcj-compat depends on:
ii fastjar 1:4.0.2-2 Jar creation utility
ii gij-4.0 4.0.2-2The GNU Java bytecode interpreter
ii libgcj6 4.0.2-2Java runtime library for use with
ii libgcj6-common4.0.2-2Java runtime library for use with
ii libjessie-java1.0.0-3free implementation of the Java Se
Versions of packages java-gcj-compat recommends:
pn libgcj6-src(no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334629: FTBFS: Could not create task or type of type junit
Matt Kraai wrote: > Package: jmock > Version: 1.0.1-1 > Severity: serious > > jmock fails to build: Needs a build-dep on ant-optional after ant reorganization. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320940: libapache2-mod-jk2 will be removed from the archive
Hi all, libapache2-mod-jk2 will be removed from the archive as it is abandoned upstream and superceeded by mod-jk. mod-jk packages for apache2 are now provided by the libapache2-mod-jk binary package on all architectures and will show up tomorrow also in etch. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332564: FTBFS: Could not create a task or type of type junit
Hi Matt, hi Trygve, Matt Kraai wrote: Package: commons-io Version: 1.0-1 Severity: serious commons-io fails to build because it cannot create a task or type of type junit: internal-test: [mkdir] Created dir: /tmp/buildd/commons-io-1.0/target/test-reports BUILD FAILED /tmp/buildd/commons-io-1.0/build.xml:80: Could not create task or type of type: junit. Looking at the diff.gz there is ant-optional missing from build-depends. @Trygve Remember the latest ant reorganization made a clean cut between core and optional tasks - and junit is an optional task. Further I ask me why you have build-deps on classpath and libgcj6 but definitly building the package with kaffe ? Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330110: kaffe: ftbfs [sparc] Configuration sparc-linux does not support the jit3 engine
tags 330110 + pending thanks Blars Blarson wrote: > Package: kaffe > Version: 2:1.1.6-2 > Severity: serious > Justification: no longer builds from source > > kaffe failed to build on a sparc buildd, duplicated on my sparc > pbuilder. This is a configure error which will be resolved in the next upload. We will just wait until it has tried to build on all architectures and therefore know if it will have any other problems. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328328: kaffe-pthreads: jar systematically throws NullPointerException
Hi Yann, Yann Dirson wrote: > Package: kaffe-pthreads > Version: 2:1.1.5-cvs20050808-2 > Severity: grave > > In the sid chroot on escher: > > $ /usr/lib/kaffe/pthreads/bin/jar > Internal error: caught an unexpected exception. Is only jar failing or also the other ones in /usr/lib/kaffe/pthreads/bin/ ? Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308848: (Untested) fix for bug: Should build depend on specific java-compiler
Package: postgis Version: 1.0.0-1 Tags: patch Hi, attached patches for build depending on a specific build compiler which should work on all architectures. These patches are untested as compilation is currently broken by the other bugs. If you need any further information or help with the java part of this package don't hesitate to ask me. Regards, Wolfgang --- debian/control.orig 2005-09-11 17:56:41.0 +0200 +++ debian/control 2005-09-11 17:57:39.0 +0200 @@ -2,7 +2,7 @@ Section: science Priority: optional Maintainer: Alex Bodnaru <[EMAIL PROTECTED]> -Build-Depends: debhelper (>= 4.0.0), devscripts, findutils, awk, binutils | binutils-multiarch, libgeos-dev, proj, postgresql-dev (>= 7.2.0), libpgjava, java-compiler, fastjar +Build-Depends: debhelper (>= 4.0.0), devscripts, findutils, awk, binutils | binutils-multiarch, libgeos-dev, proj, postgresql-dev (>= 7.2.0), libpg-java, jikes-classpath, fastjar Standards-Version: 3.6.1 Package: libpostgis1-pg74 @@ -45,7 +45,7 @@ Section: science Priority: optional Architecture: all -Depends: libpostgis, libpgjava +Depends: libpostgis, libpg-java Replaces: libpostgis-jdbc, libpostgisjava Description: geographic objects support for PostgreSQL. JDBC PostGIS adds support for geographic objects to the --- debian/rules.orig 2005-09-11 17:59:04.0 +0200 +++ debian/rules 2005-09-11 17:59:28.0 +0200 @@ -166,7 +166,7 @@ # commands to install the package into debian/tmp $(MAKE) install DESTDIR=$(DESTDIR) - DEBUGJAR=postgis_debug.fastjar JAR=fastjar $(MAKE) -C jdbc2 install DESTDIR=$(DESTDIR)$(JAVA_PATH) + DEBUGJAR=postgis_debug.fastjar JAR=fastjar JAVAC=jikes-classpath $(MAKE) -C jdbc2 install DESTDIR=$(DESTDIR)$(JAVA_PATH) cp utils/*.pl $(DESTDIR)/$(bindir) mkdir -p $(DESTDIR)/$(main_bin)
Bug#318785: kaffe: Please depend on libgmp3c2 instead of libgmp
Steve Langasek wrote: >>However, a new kaffe release 1.1.6 will come out and we decided to >>wait for it. It will take maybe one week or so. > > > Well, this was written on the 20th; it's now been 12 days. Is 1.1.6 out? > When might this version find its way to the archive? Hi Steve, 1.1.6 will take a bit longer (maybe end of summer). I already prepared a 1.1.5-4 for upload which addresses this and other packaging related stuff. However Arnaud is currently very busy (moves to his new house) and it seems he has not yet uploaded it. I will ask him if he is able to upload soon. Thanks, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319168: gjdoc unconditionally depends on kaffe, currently uninstallable
Matthias Klose wrote: > Package: gjdoc > Version: 0.7.5-1 > Severity: serious > > gjdoc currently is not installable in unstable. It should definitely > depend on the java1-runtime or java2-runtime alternative. At least > java-gcj-compat is a working alternative. Hi Matthias, you are right - I also thought of decoupling gjdoc from kaffe. This also relates to my bug report #317821 on java-gcj-compat for a javadoc wrapper script to use java-gcj vm to execute gjdoc and not a directly link. gjdoc should depends on java1-runtime | java2runtime and in the gjdoc script if JAVA is not set the current java executable set by the alternative system /usr/bin/java should be used. This way kaffe's javadoc would call the gjdoc executable through a wrapper with JAVA=/usr/lib/kaffe/bin/java gjdoc and java-gcj with also with it's own wrapper. However, I would like to hear the opinion of Michael Koch who primarily maintains gjdoc in the pkg-java team. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318785: kaffe: Please depend on libgmp3c2 instead of libgmp
Andreas Jochens wrote: > Package: kaffe > Version: 2:1.1.5-3 > Severity: serious > Tags: patch > > Please change libgmp3 to libgmp3c2 in debian/shlibs.local. Otherwise > kaffe binary packages will depend on libgmp3 which is no longer built > by the gmp source package. > Hi Andreas, we will wait for a new upstream release before uploading. Currently gmp is not yet build on m68k, so we have to wait anyway. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315038: Fixes for library issues
Josh Partlow wrote: > Hello, > > These are the changes I needed to make to get the tomcat5 packages > working: > [...] > The index page now displays. > > I hope the above is helpful. This is really helpful - thanks a lot. I think you are running tomcat5 on a non-free JDK ? Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#195293: Removal from archive ?
Hi Yven, wonder why this package is not yet removed as you said on October 2003. Its also superceeded IMHO by java-package which provides a method to install also IBM jdk/jre binary packages. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307211: Patch for building on both sarge and sid
tags 307211 patch stop Hi, with jikes-kaffe instead of jikes-classpath this package builts on both sarge and sid systems. Wolfgang --- debian/control.orig 2005-05-03 08:48:35.0 + +++ debian/control 2005-05-03 08:49:50.0 + @@ -2,12 +2,12 @@ Section: contrib/text Priority: optional Maintainer: Mark Johnson <[EMAIL PROTECTED]> -Build-Depends-Indep: debhelper (>= 4), arbortext-catalog, libsaxon-java (>= 6.5.4), jikes-classpath, fastjar +Build-Depends-Indep: debhelper (>= 4), arbortext-catalog, libsaxon-java (>= 6.5.4), jikes-kaffe, fastjar Standards-Version: 3.6.1 Package: saxon-catalog Architecture: all -Depends: java-common, libsaxon-java (>= 6.5.4), arbortext-catalog, libcrimson-java, kaffe | java-runtime +Depends: java-common, libsaxon-java (>= 6.5.4), arbortext-catalog, libcrimson-java, kaffe | java1-runtime | java2-runtime Suggests: docbook-xsl (>= 1.45) Description: Catalog support and wrapper for the Saxon XSLT Processor This package provides a simple front-end to Saxon for processing XML --- debian/rules.orig 2005-05-03 08:48:05.0 + +++ debian/rules2005-05-03 08:48:26.0 + @@ -11,7 +11,7 @@ build-stamp: dh_testdir if [ ! -d build ]; then mkdir build; fi - jikes-classpath -cp /usr/share/java/saxon.jar:/usr/share/java/catalog.jar -sourcepath src -d build `find src -name \*.java` + jikes-kaffe -cp /usr/share/java/saxon.jar:/usr/share/java/catalog.jar -sourcepath src -d build `find src -name \*.java` (cd build; fastjar -cf ../saxon-catalog.jar `find . -name \*.class` ) touch build-stamp
Bug#306639: Set severity as discussed to wishlist
severity 306639 wishlist thanks Set the severity to whishlist as decided by discussion between Andreas Jochen, Arnaud Vandyck and release team. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304524: libxerces2-java: FTBFS: Semantic Errors
Michael Koch wrote: On Sat, Apr 16, 2005 at 07:40:27PM +0200, Wolfgang Baer wrote: [...] (2) Include DOM Level 2 source classes in the debian directory and use the trick that source takes precedence over binary classes from the runtime during compilation. If no one has objections or another working approach I will prepare a new upload for possibility 2. In order not to incluce DOM Level 2 compatible classes in several packages we should either create a package for them and make packages depend on it or use patches (writing them if needed) to make the software build with DOM level 3. That isnt too hard either. Hi Michael, well it's not that easy. For the first suggestion: We have already a DOM Level 2 package (libjaxp1.2-java), but the problem is to use it INSTEAD the system classes of this namespace during compilation. This is possible with the proprietary vm's but I haven't succeeded with the free vm's and believe me I invested a lot of time to try all possible stuff (all bootclasspath manipulation options for both kaffe and sablevm). After several hours of tests I found the following: Using jikes as the build compiler needs an explicit setting of the bootclasspath. So compilation against kaffe would need e.g. -bootclasspath /usr/share/kaffe/Klasses.jar to succeed. If we at this point prepend the bootclasspath with the needed DOM Level 2 package it takes precedence over the DOM classes in the runtime jar. So jikes -bootclasspath \ /usr/share/jaxp-1.2.jar:/usr/share/kaffe/Klasses.jar would work for compilation. However we use ant to build. The problem is that the 1.6.2 release of ant is based on a jikes compiler implementation which had no -bootclasspath option - therefore all bootclasspath/sourcepath/extdirs options given in the javac task in the build.xml file has no effect and only gets appended to the classpath. This is changed in the 1.6.3beta1 release of ant which can handle the bootclasspath and other options of newer jikes versions. With this version it would only be needed to patch the build.xml file used to include a bootclasspath option as described above where the packages which should be used for overriding the runtime classes DURING compilation are prepended. I don't know if it is wanted to update libant1.6-java to a beta release such close to the sarge release. However we could backport the jikes implementation - this is what I have done for testing purposes. But there is also a good change that this different behaviour of ant together with jikes as build compiler will break compilation of other packages which would be a problem to find out such close to release. So my prefered way would be to use my given option with including the DOM Level 2 sources for getting libxerces2-java to compile for the near sarge release. After sarge - we can switch to the ant 1.6.3beta1 release and compile without the included DOM Level 2 sources through a patched build.xml via the bootclasspath option. For the second suggestion: Although maybe possible - it will break ALL applications which use the experimental DOM Level 3 implementation parts included in xerces 2.6.2. This experimental DOM Level 3 implementation in xerces uses for some parts (which weren't specified in the draft Level 3 implementation at the time xerces released) different namespaces. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304524: libxerces2-java: FTBFS: Semantic Errors
Roland Stigge wrote:
Package: libxerces2-java
Version: 2.6.2-1
Severity: serious
Hi,
building the package libxerces2-java in a clean sid build environment
(with pbuilder) on i386 results in:
[...]
[xjavac] Found 13 semantic errors and issued 5 warnings compiling
"/tmp/buildd/libxerces2-java-2.6.2/build/src/org/apache/xerces/dom/NodeImpl.java":
[xjavac] <---
[xjavac]118. public abstract class NodeImpl
[xjavac]119. implements Node, NodeList, EventTarget, Cloneable,
Serializable{
[xjavac]
-->
[xjavac] *** Semantic Error: The return type of method "org.apache.xerces.dom3.TypeInfo
getSchemaTypeInfo();" does not match the return type of the accessible method "org.w3c.dom.TypeInfo
getSchemaTypeInfo();" declared in type "org.w3c.dom.Element".
Hi all,
after some investigation this error is caused by the update of the
org.w3c.* classes in the free runtimes to DOM Level 3.
Its basically the same problem I struggled with during the process
of moving libxalan2-java and libpgjava to main.
There are two possiblities:
(1) Use JDK 1.4 to build as it has DOM Level 2
I think we all agree that this is NO option !
(2) Include DOM Level 2 source classes in the debian directory
and use the trick that source takes precedence over binary classes
from the runtime during compilation.
If no one has objections or another working approach I will prepare
a new upload for possibility 2.
Wolfgang
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303218: We are working on it
This is just for the record, that we are working on a new revision. There are interferences between the configure and ant build method available in this package - which does no harm on my i386 system but prevents building on powerpc by Arnaud. We have to figure some things out and are currently both a bit in time problems - but be sure it will be worked out in the next days. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303218: libgnumail-java: FTBFS: Compiler error
Daniel Schepler wrote: Package: libgnumail-java Severity: serious Version: 1.0-4 From my build log, using pbuilder in an i386 chroot: ... gnumail: [javac] Compiling 115 source files to /tmp/buildd/libgnumail-java-1.0/classes ... [javac] Found 1 semantic error compiling "/tmp/buildd/libgnumail-java-1.0/source/gnu/mail/util/PrintStreamLogger.java": [javac] 38. public class PrintStreamLogger [javac] ^---^ [javac] *** Semantic Error: The abstract method "void error(java.lang.String $1, java.lang.Throwable $2);", inherited from type "gnu.inet.util.Logger", is not implemented in the non-abstract class "gnu.mail.util.PrintStreamLogger". Thats really strange - as I built this package in a pbuilder before. Arnaud build the package also on his box before the upload. But somehow all the patches mentioned in the changelog are missing and some strange config.guess files are included intead. My diff.gz here for this version is 3kB in size but the diff.gz in the archive is > 60 kB in size. There went something completely wrong. I will prepare a new version this evening. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302114: mapserver: Depends on libgcc1 from experimental
Package: mapserver Severity: serious Hi, it seems the build system of the uploaded mapserver binary (i386) used the libgcc1 from experimental. cgi-mapserver: Depends: libgcc1 (>= 1:4.0) but 1:3.4.3-12 is to be installed Regards, Wolfgang -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11.6 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300748: Batik goes into sarge tonight
batik 1.5.1 is scheduled for sarge tonight. Therefore this bug should be closed now. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300388: libxml-commons-resolver1.1-java: FTBFS: NullPointerException
Hi Grzegorz, Grzegorz B. Prokopski wrote: Hi, That was an issue with setting default locales, and is already fixed in unstable (fix will be propagated into testing soon). Please just try to use ANT with this version and everything should be all right. Or actually you don't need to do anything :-) Well there was something fixed with an NMU and it has already propagated to testing - but it didn't fix the sablevm ant interaction problem. I am running uptodate unstable and everytime i try to build a package with ant and sablevm I run in this problem - for example bsh-1.3.0 with sablevm in the clean target: java.lang.NullPointerException at java.text.DecimalFormatSymbols.setCurrency (DecimalFormatSymbols.java:397) at java.text.DecimalFormatSymbols.DecimalFormatSymbols (DecimalFormatSymbols.java:151) at java.text.NumberFormat.computeInstance (NumberFormat.java:327) at java.text.NumberFormat.getNumberInstance (NumberFormat.java:456) at java.text.NumberFormat.getInstance (NumberFormat.java:381) at java.text.MessageFormatElement.setLocale (MessageFormat.java:90) at java.text.MessageFormat.scanFormat (MessageFormat.java:314) at java.text.MessageFormat.applyPattern (MessageFormat.java:335) at java.text.MessageFormat.formatInternal (MessageFormat.java:465) at java.text.MessageFormat.format (MessageFormat.java:403) at java.text.MessageFormat.format (MessageFormat.java:518) at java.text.Format.format (Format.java:101) at org.apache.tools.ant.util.DateUtils.formatElapsedTime (DateUtils.java:132) at org.apache.tools.ant.DefaultLogger.formatTime (DefaultLogger.java:276) at org.apache.tools.ant.DefaultLogger.buildFinished (DefaultLogger.java:156) at org.apache.tools.ant.Project.fireBuildFinished (Project.java:1796) at org.apache.tools.ant.Main.runBuild (Main.java:693) at org.apache.tools.ant.Main.startAnt (Main.java:188) at org.apache.tools.ant.Main.start (Main.java:151) at org.apache.tools.ant.Main.main (Main.java:241) at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) at java.lang.VirtualMachine.main (VirtualMachine.java:108) The problem is also reported as bug #293509 on sablevm. The FTBS of libcommons-jexl-java is also the same error (#299125). Although marked as done by Arnaud (because of the sablevm-classlib NMU) it does FTBS for me (just tried). dpkg -l | grep sablevm ii libsablevm-classlib 1.1.9.dfsg1-0.1 ii libsablevm-native1 1.1.9.dfsg1-0.1 ii libsablevm1 1.1.9-1 ii sablevm 1.1.9-1 Are you planning to make a package of the 1.11.1 release ? I hope this release will fix all the FTBS bugs against the packages build with ant / sablevm combination. Grzergorz, if I can help you with testing a new sablevm package send me an email. Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288009: batik 1.5.1 would break fop
Steve Langasek wrote: On Thu, Mar 10, 2005 at 06:22:19PM +0100, Wolfgang Baer wrote: >>fop is currently not in testing although a valid candidate. A "solution" to the problem would be to upgrade batik to 1.5.1 and also to upload a new fop package with an embedded batik library in the current version (with the affected Squiggle class files removed from the library). fop is not really a valid candidate, although it appears to be in grep-excuses. Both libfop-java and libfop-java-doc are uninstallable on their own right in unstable, because libfop-java depends on fop and fop conflicts with libfop-java. You can safely ignore this package for the time being... There was a small discussion on debian-java the last minutes. I will prepare a patched fop release which should compile against batik 1.5.1 Should therefore the libfop-java and libfop-java-doc binary packages removed in the new package ? I think they are transitional packages not needed anymore as fop is not in testing at all. Am I right ? (I CC debian-java for this binary package removal question) Regards, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288009: batik 1.5.1 would break fop
Hi, I prepared a package for the batik 1.5.1 upstream release. However during testing the package I realized that batik 1.5.1 breaks fop ! As far as I see no other packages depend on libbatik-java. fop is currently not in testing although a valid candidate. A "solution" to the problem would be to upgrade batik to 1.5.1 and also to upload a new fop package with an embedded batik library in the current version (with the affected Squiggle class files removed from the library). What do you think ? Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
