On Tue, Sep 14, 2004 at 06:35:40AM -0500, Dirk Eddelbuettel wrote: > I haven't seen your bug report in detail (having delivery issues with > @debian.org mail, some has been days late), but octave2.0 is unlikely to > change: > -- code development was frozen / stopped years ago, all development went > into octave2.1 > -- octave2.0 is there for "legacy" code > -- it doesn't build on all arches, and never has as it requires a pre-3.0.0 > gcc/g++ version, and those were problematic on hppa and ia64 > -- if it is fscked on arm, no one will fix it unless the arm people do > So I would much prefer to just forget about it. If it exists in the others > arches, can we override build attempts on arm and get on with life? > Realistically, few to no people would use octave on arm anyway, and for the > few brave ones, we have a working octave2.1. > I'll intend tag this is upstream+wontfix and would like to lower severity as > well. It is a bug, but far from RC in my book. It is a serious bug in version 2.0.17-9 of octave2.0 that it fails to build on arm where it built successfully before. However, the other architectures all have 2.0.17-8 in testing, where arm has 2.0.17-7 (presumably getting in at some point in the past when arm was being ignored), so ignoring the build failure altogether is not sufficient to ensure a releasable octave2.0 package in sarge. Either someone needs to fix octave2.0's build on arm, or the out-of-date binaries need to be removed from both testing and unstable before release. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature