[Pkg-octave-devel] Re: Bug#400214: octave2.1-forge: include top-level dir /octave2.1-forge/

[Thomas Weber]

[sent to the list only for discussion; it's not of much use for the bug
report]

Am Sonntag, den 26.11.2006, 15:05 -0800 schrieb Steve Langasek:
> On Sun, Nov 26, 2006 at 09:53:34PM +0100, Thomas Weber wrote:
> > > > > The ia64 package includes a top-level directory ./octave2.1-forge/
> 
> > > > >From the build logs of ia64 (caballero) and sparc (mrpurply):
> 
> > > > 	"make: octave-config: Command not found"
> 
> > > > (This results in an empth xpath setting, which is responsible for this
> > > > breakage). 
> 
> > > > Well, I suspect it's the following: 
> 
> > > > http://lists.debian.org/debian-devel/2006/01/msg01566.html
> 
> > > > caballero seems to have been fixed, so a rebuild would be enough. 
> 
> > > Please fix your package instead to fail to build when there is a problem
> > > with octave-config, instead of misbuilding in this fashion.
> 
> > Yes, and then?
> 
> And then the bug in octave2.1-forge is fixed, and there's something I can
> point to in bugging the buildd admins to fix the chroot.
> 
> In any case, it's not an appropriate use of a binNMU to rebuild on ia64 when
> there's still a sourceful bug that allowed this misbuild in the first place.

With the upload octave2.1-forge on its way, we need to get the
autobuilders fixed. I therefore propose to use either octplot or
semidef-oct as a guinea pig. We introduce an (obviously failing call) of
octave-config in their build scripts and upload. 

Reasoning: these two package compile rather fast, so we don't put too
much additional load on the buildds, especially for slower arches. Both
packages don't have any reported bugs and their latest version is in
testing.

This proposal has not been discussed with Steve, but I don't think he
really cares which package shows the bug.

	Thomas