Re: gcj/java status
On Fri, Nov 03, 2006 at 07:37:33AM +0100, Matthias Klose wrote: > > > no, only the upstream tarball is used from gcc-4.1-source. the > > > patches are used from the gcj-4.1 source. The patches in > > > gcc-4.1-source are needed to build cross compilers, based on > > > gcc-4.1-source. > > My point was that the upstream tarball shipped within the gcc-4.1 source > > package differs between 4.1.1-13 and 4.1.1-19, and according to the > > changelog appears to incorporate additional changes from upstream svn. Have > > I misunderstood? > the upstream tarball has the same code, just some more GFDL'ed files > removed. changes from upstream svn are included as a diff. Ok, thanks for the clarification. gcj-4.1 4.1.1-17 is unblocked, in anticipation of the arm upload. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Steve Langasek writes: > On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote: > > Steve Langasek writes: > > > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > > > Please consider moving the following packages to testing: > > > > > gcj-4.1 > > > > I'm wondering whether the build-dependencies of gcj-4.1 are really > > > accurate. > > > Is it really the case that gcj-4.1 will build against any version of > > > gcc-4.1-source between 4.1.1 and 4.1.2? How is this done, when the > > > gcc-4.1 > > > source package appears to incorporate various updates from svn into the > > > actual tarball being distributed? Doesn't this imply that gcj-4.1 and > > > gcc-4.1 will need to be updated in lockstep? > > > no, only the upstream tarball is used from gcc-4.1-source. the > > patches are used from the gcj-4.1 source. The patches in > > gcc-4.1-source are needed to build cross compilers, based on > > gcc-4.1-source. > > My point was that the upstream tarball shipped within the gcc-4.1 source > package differs between 4.1.1-13 and 4.1.1-19, and according to the > changelog appears to incorporate additional changes from upstream svn. Have > I misunderstood? the upstream tarball has the same code, just some more GFDL'ed files removed. changes from upstream svn are included as a diff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote: > Steve Langasek writes: > > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > > Please consider moving the following packages to testing: > > > gcj-4.1 > > I'm wondering whether the build-dependencies of gcj-4.1 are really > > accurate. > > Is it really the case that gcj-4.1 will build against any version of > > gcc-4.1-source between 4.1.1 and 4.1.2? How is this done, when the gcc-4.1 > > source package appears to incorporate various updates from svn into the > > actual tarball being distributed? Doesn't this imply that gcj-4.1 and > > gcc-4.1 will need to be updated in lockstep? > no, only the upstream tarball is used from gcc-4.1-source. the > patches are used from the gcj-4.1 source. The patches in > gcc-4.1-source are needed to build cross compilers, based on > gcc-4.1-source. My point was that the upstream tarball shipped within the gcc-4.1 source package differs between 4.1.1-13 and 4.1.1-19, and according to the changelog appears to incorporate additional changes from upstream svn. Have I misunderstood? > > A build failure on arm is also the only thing keeping this updated version > > of gcj-4.1 from being hinted into testing, though that seems to have been an > > OOD error on the buildd; given back now. > yes, thanks. Built and uploaded, just waiting for libssp0 binary removal now. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
On Thu, Nov 02, 2006 at 01:11:24PM +0100, Matthias Klose wrote: > Steve Langasek writes: > > so in the absence of any movement in this area, I still need to > > know what Debian is going to do with gcj on ARM for the upcoming etch > > release. > in the worst case, remove the binaries built from gcj-4.1, > ecj-bootstrap-gcj. How many build-dependencies will be broken? Didn't > check, but it shouldn't be that many, because most packages are binary > all. Here's what I get from 'dak rm': $ dak rm -R -n -a arm -s testing ecj-bootstrap gcj-4.1 Will remove the following packages from testing: ecj-bootstrap |3.2.1-3 | source gappletviewer-4.1 | 4.1.1-13 | arm gcj-4.1 | 4.1.1-13 | source, arm gcj-4.1-base | 4.1.1-13 | arm gij-4.1 | 4.1.1-13 | arm libgcj7-0 | 4.1.1-13 | arm libgcj7-awt | 4.1.1-13 | arm libgcj7-dbg | 4.1.1-13 | arm libgcj7-dev | 4.1.1-13 | arm [...] Checking reverse dependencies... [...] ** airport-utils has an unsatisfied dependency on arm: libgcj7-awt ** libjlha-java-doc-ja has an unsatisfied dependency on arm: classpath-doc ** libgcj-doc has an unsatisfied dependency on arm: gcj-4.1-base (>= 4.1.1) ** tomcat5.5 has an unsatisfied dependency on arm: ecj-bootstrap ** pdftk has an unsatisfied dependency on arm: libgcj7-0 (>= 4.1.1-12) ** libgcj7-jar has an unsatisfied dependency on arm: gcj-4.1-base (>= 4.1.1) ** libgcj7-jar has an unsatisfied dependency on arm: libgcj7-0 (>= 4.1.1) ** gcj has an unsatisfied dependency on arm: gcj-4.1 (>= 4.1.1-2) ** libgcj-bc has an unsatisfied dependency on arm: libgcj7-0 (>= 4.1.1-2) ** libgcj7-src has an unsatisfied dependency on arm: gcj-4.1-base (>= 4.1.1) ** libgcj7-src has an unsatisfied dependency on arm: gcj-4.1 (>= 4.1.1) ** gij has an unsatisfied dependency on arm: gij-4.1 (>= 4.1.1-2) ** turkey has an unsatisfied dependency on arm: libgcj7-awt ** trang has an unsatisfied dependency on arm: libgcj7-0 (>= 4.1.1-12) [...] ** gcc-defaults has an unsatisfied build-dependency: gcj-4.1-base (>= 4.1.1) ** gjdoc has an unsatisfied build-dependency: gcj-4.1 (>= 4.1.1-15) ** java-gcj-compat has an unsatisfied build-dependency: gcj-4.1 (>= 4.1.1-13) ** kaffe has an unsatisfied build-dependency: ecj-bootstrap (>= 3.1.2-4) ** libcommons-lang-java has an unsatisfied build-dependency: ecj-bootstrap ** libitext-java has an unsatisfied build-dependency: ecj-bootstrap ** libjcommon-java has an unsatisfied build-dependency: ecj-bootstrap ** libjgoodies-forms-java has an unsatisfied build-dependency: classpath-doc ** libjlha-java has an unsatisfied build-dependency: classpath-doc ** pdftk has an unsatisfied build-dependency: gcj-4.1 ** xml-im-exporter has an unsatisfied build-dependency: classpath-doc ** xulrunner has an unsatisfied build-dependency: ecj-bootstrap (>= 3.1.2-6) Of these, the arch: any packages appear to be pdftk, gcc-defaults, gjdoc, java-gcj-compat, xulrunner, and trang. The gcc-defaults ones are probably easy enough to clear out if it's a question of losing java on arm, but xulrunner/gjdoc are less friendly to be dropping, particularly at this point in the release cycle. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Steve Langasek writes: > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > Please consider moving the following packages to testing: > > > gcj-4.1 > > I'm wondering whether the build-dependencies of gcj-4.1 are really accurate. > Is it really the case that gcj-4.1 will build against any version of > gcc-4.1-source between 4.1.1 and 4.1.2? How is this done, when the gcc-4.1 > source package appears to incorporate various updates from svn into the > actual tarball being distributed? Doesn't this imply that gcj-4.1 and > gcc-4.1 will need to be updated in lockstep? no, only the upstream tarball is used from gcc-4.1-source. the patches are used from the gcj-4.1 source. The patches in gcc-4.1-source are needed to build cross compilers, based on gcc-4.1-source. > A build failure on arm is also the only thing keeping this updated version > of gcj-4.1 from being hinted into testing, though that seems to have been an > OOD error on the buildd; given back now. yes, thanks. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Steve Langasek writes: > so in the absence of any movement in this area, I still need to > know what Debian is going to do with gcj on ARM for the upcoming etch > release. in the worst case, remove the binaries built from gcj-4.1, ecj-bootstrap-gcj. How many build-dependencies will be broken? Didn't check, but it shouldn't be that many, because most packages are binary all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Andrew Haley writes: > Steve Langasek writes: > > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > > Please consider moving the following packages to testing: > > > > > - arm: debian only port, not yet submitted to upstream; runtime is > > >currently non-functional, testsuite shows failures for all > > >interpreter test cases. > > >#388505: segfaults in gcj-dbtool-4.1, not addressed. > > > > > Going back to gcj-4.0 for arm could be an alternative, at least simple > > > programs did compile to native code and run sucessfully. The testsuite > > > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back > > > to 4.0 for arm would mean to use an older java-gcj-compat for arm as > > > well. Another alternative would be to replace the gcj runtime with > > > kaffe, using patches from upstream CVS (suggested by Dalibor Topic). > > > > > For etch, I currently don't have the time and hardware resource to > > > spend work on arm. > > > > Could Andrew be correct that this is a sign of an improved testsuite, > > not a regression in the functionality for arm? > > > > A build failure on arm is also the only thing keeping this updated version > > of gcj-4.1 from being hinted into testing, though that seems to have been > an > > OOD error on the buildd; given back now. > > Is no-one interested in actually fixing this? We could, for the first > time, get gcj running properly on ARM. Most of the arm port maintainers seem to be MIA. I tried to contact Phil Blundell during the past three or four months, but didn't get any reply. We need to get the copyright assignment from Phil to properly submit that code upstream. Steve did point out the lack of development machines for ARM, maybe we should update that fact on the matrix of the etch release architectures as well. I will not have time for gcj work on ARM for the next three or four weeks beeing on conferences/vacations. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
On Wed, Nov 01, 2006 at 09:53:37AM +, Andrew Haley wrote: > > > Going back to gcj-4.0 for arm could be an alternative, at least simple > > > programs did compile to native code and run sucessfully. The testsuite > > > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back > > > to 4.0 for arm would mean to use an older java-gcj-compat for arm as > > > well. Another alternative would be to replace the gcj runtime with > > > kaffe, using patches from upstream CVS (suggested by Dalibor Topic). > > > For etch, I currently don't have the time and hardware resource to > > > spend work on arm. > > Could Andrew be correct that this is a sign of an improved testsuite, > > not a regression in the functionality for arm? > > A build failure on arm is also the only thing keeping this updated version > > of gcj-4.1 from being hinted into testing, though that seems to have been > an > > OOD error on the buildd; given back now. > Is no-one interested in actually fixing this? We could, for the first > time, get gcj running properly on ARM. I would love to see that happen, but I'm not an ARM porter and don't have access to an appropriate ARM development environment that would let me work on this; so in the absence of any movement in this area, I still need to know what Debian is going to do with gcj on ARM for the upcoming etch release. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Steve Langasek writes: > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > Please consider moving the following packages to testing: > > > - arm: debian only port, not yet submitted to upstream; runtime is > >currently non-functional, testsuite shows failures for all > >interpreter test cases. > >#388505: segfaults in gcj-dbtool-4.1, not addressed. > > > Going back to gcj-4.0 for arm could be an alternative, at least simple > > programs did compile to native code and run sucessfully. The testsuite > > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back > > to 4.0 for arm would mean to use an older java-gcj-compat for arm as > > well. Another alternative would be to replace the gcj runtime with > > kaffe, using patches from upstream CVS (suggested by Dalibor Topic). > > > For etch, I currently don't have the time and hardware resource to > > spend work on arm. > > Could Andrew be correct that this is a sign of an improved testsuite, > not a regression in the functionality for arm? > > A build failure on arm is also the only thing keeping this updated version > of gcj-4.1 from being hinted into testing, though that seems to have been an > OOD error on the buildd; given back now. Is no-one interested in actually fixing this? We could, for the first time, get gcj running properly on ARM. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > Please consider moving the following packages to testing: > gcj-4.1 I'm wondering whether the build-dependencies of gcj-4.1 are really accurate. Is it really the case that gcj-4.1 will build against any version of gcc-4.1-source between 4.1.1 and 4.1.2? How is this done, when the gcc-4.1 source package appears to incorporate various updates from svn into the actual tarball being distributed? Doesn't this imply that gcj-4.1 and gcc-4.1 will need to be updated in lockstep? > java-gcj-compat > gcc-defaults > ecj-bootstrap > gjdoc The rest of these have all been updated (I assume -- they're not all frozen, so I think some of them went in on their own?). > - alpha: #390982, bus errors in the interpreter, doesn't show any >build issues, status of the runtime is rather unknown. Falk? Bus errors on alpha are always non-fatal; all they do is dump errors to the kernel log. (This is also the default on hppa, but on alpha it's not even possible to get SIGBUS except with a kernel patch.) > - arm: debian only port, not yet submitted to upstream; runtime is >currently non-functional, testsuite shows failures for all >interpreter test cases. >#388505: segfaults in gcj-dbtool-4.1, not addressed. > Going back to gcj-4.0 for arm could be an alternative, at least simple > programs did compile to native code and run sucessfully. The testsuite > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back > to 4.0 for arm would mean to use an older java-gcj-compat for arm as > well. Another alternative would be to replace the gcj runtime with > kaffe, using patches from upstream CVS (suggested by Dalibor Topic). > For etch, I currently don't have the time and hardware resource to > spend work on arm. Could Andrew be correct that this is a sign of an improved testsuite, not a regression in the functionality for arm? A build failure on arm is also the only thing keeping this updated version of gcj-4.1 from being hinted into testing, though that seems to have been an OOD error on the buildd; given back now. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Matthias Klose writes: > > - arm: debian only port, not yet submitted to upstream; runtime is >currently non-functional, testsuite shows failures for all >interpreter test cases. >#388505: segfaults in gcj-dbtool-4.1, not addressed. > > Going back to gcj-4.0 for arm could be an alternative, at least > simple programs did compile to native code and run sucessfully. As I understand it, Debian has a private patch for libffi closures. This is needed to make the interpreter work. No-one except Debian has the gcj interpreter working on ARM. See http://gcc.gnu.org/ml/java/2006-08/msg00123.html This patch looks to me like unwinder data is missing, and on systems that use DWARF unwinding this will cause exceptions to fail. I'm happy to help anyone who wants to get these test filaures fixed. But really, this patch should be pushed upstream rather than being Debian local. > The testsuite in 4.0 shows over 100 test failures, in 4.1 over > 700. Mmm, but I suspect that's because more is being tested, not because it's worse. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcj/java status
[didn't see this email reaching the lists, sending it again] Please consider moving the following packages to testing: gcj-4.1 java-gcj-compat gcc-defaults ecj-bootstrap gjdoc The packages don't show regressions compared to the versions currently in testing. For m68k, both a working compiler and runtime is provided with gcj-4.1.1-16/17. Architecture specific problems (testing and unstable) are: - s390: #338755, ecj won't be built anymore with eclipse-3.2 (although eclipse isn't yet supported on s390), doesn't seem to be an issue. - alpha: #390982, bus errors in the interpreter, doesn't show any build issues, status of the runtime is rather unknown. Falk? - hppa: #390982, bus errors in the interpreter, worked around by a wrapper to gij; forwarded, status unknown. #388505: segfaults in gcj-dbtool-4.1, worked around in the packages, unable to use the byte-code compiled to native code. - arm: debian only port, not yet submitted to upstream; runtime is currently non-functional, testsuite shows failures for all interpreter test cases. #388505: segfaults in gcj-dbtool-4.1, not addressed. Going back to gcj-4.0 for arm could be an alternative, at least simple programs did compile to native code and run sucessfully. The testsuite in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back to 4.0 for arm would mean to use an older java-gcj-compat for arm as well. Another alternative would be to replace the gcj runtime with kaffe, using patches from upstream CVS (suggested by Dalibor Topic). For etch, I currently don't have the time and hardware resource to spend work on arm. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
