[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#127783: acknowledged by developer (Re: Bug#127783: gcc-3.0-source: java selftest fail)



owner@bugs.debian.org (Debian Bug Tracking System) writes:

> This is an automatic notification regarding your Bug report
> #127783: gcc-3.0-source: java selftest fail,
> which was filed against the gcc-3.0 package.
> 
> It has been closed by one of the developers, namely
> Matthias Klose <doko@cs.tu-berlin.de>.
> 
> Their explanation is attached below.  If this explanation is
> unsatisfactory and you have not received a better one in a separate
> message then please contact the developer, by replying to this email.
> 
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)
> 
> Received: (at 127783-done) by bugs.debian.org; 5 Jan 2002 02:13:25 +0000
> >From doko@cs.tu-berlin.de Fri Jan 04 20:13:25 2002
> Return-path: <doko@cs.tu-berlin.de>
> Received: from mail.cs.tu-berlin.de [130.149.17.13] (root)
> 	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
> 	id 16MgKq-0002aW-00; Fri, 04 Jan 2002 20:13:24 -0600
> Received: from bolero.cs.tu-berlin.de (doko@bolero.cs.tu-berlin.de [130.149.19.1])
> 	by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id DAA05290;
> 	Sat, 5 Jan 2002 03:10:21 +0100 (MET)
> Received: (from doko@localhost)
> 	by bolero.cs.tu-berlin.de (8.10.2+Sun/8.9.3) id g052ALe25556;
> 	Sat, 5 Jan 2002 03:10:21 +0100 (MET)
> From: Matthias Klose <doko@cs.tu-berlin.de>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Message-ID: <15414.24716.888496.324655@gargle.gargle.HOWL>
> Date: Sat, 5 Jan 2002 03:10:20 +0100
> To: Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>,
>         127783-done@bugs.debian.org
> CC: Roman Zippel <zippel@linux-m68k.org>
> Subject: Re: Bug#127783: gcc-3.0-source: java selftest fail
> In-Reply-To: <[🔎] 87wuyyufhc.fsf@dual.intern.brederlow.de>
> References: <[🔎] E16MW2C-0003cM-00@dual>
> 	<[🔎] 15413.52277.286772.79744@gargle.gargle.HOWL>
> 	<[🔎] 87wuyyufhc.fsf@dual.intern.brederlow.de>
> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
> Delivered-To: 127783-done@bugs.debian.org
> 
> Goswin Brederlow writes:
> > Matthias Klose <doko@cs.tu-berlin.de> writes:
> > 
> > > Goswin Brederlow writes:
> > > > Package: gcc-3.0
> > > > Version: 1:3.0.3-1
> > > > Severity: normal
> > > > 
> > > > The package doesn't pass its selftests and _should_fail_ to build.
> > > > It should fail when the first make fails and not continue with other
> > > > selftest, otherwise errors get overlocked.
> > > 
> > > huh? then we'll never have a build which succeeds ...
> > 
> > Some test are expected to fail, thats fine. I hope the expected
> > failures don't make the make return with an error too.
> > 
> > But an unexpected failure suggests a new error. That should fail and
> > stop the build.
> 
> fine, if you want this behaviour on m68k, I'll do it. What do we gain?
> Roman Zippel submitted the patches to build gcj on m68k, so you may
> want to ask him for the failures.
> 
> > > you deleted the interesting part. where/why doesn't it continue?
> > 
> > It does. I think the next one was the gcc tests. That shouldn't be
> > caried out since the libjava tests failed (unexpectedly).
> 
> so all is ok. regressions on architecutures, which aren't "supported"
> upstream in 3.0 (Debian has it's own patches for m68k, hppa and
> sparc64) are fairly common. Sure, we can just disbale running the
> testsuite.

This was all on i386, m68k is still building (and looks way way
worse). I would think that at least on i386 the selftest results
should be as expected.

Its not only gcj that has unexpected failures, its just the first. gcc
and g++ also have unexpected failures and unexpected successes (which
probably are ok).


Can you run the testsuite with the compiled debs or does it need to be
in  place in the sources? If the first disabling them might be a good
idea. They just take way to much time and thats just waste if noone
cares about them anyway.
Eigther we care about the testresults, then the build should fail if
they fail, or we should not care and then not do them. I'm for
failing, because those tests are a good thing.

What architectures are officially supported upstream in 3.0?

MfG
        Goswin



Reply to: