Am Montag, den 17.09.2007, 20:33 -0700 schrieb Steve Langasek:
> Andreas,
>
> On Mon, Sep 17, 2007 at 10:46:00PM +0200, Andreas Tille wrote:
>
> > according to
>
> > http://qa.debian.org/excuses.php?package=blitz%2B%2B
>
> > there is no libatlas.so.3 available for arm which prevents blitz++
> > from entering testing. I also did not found any useful atlas
> > implementation for arm:
>
> >
> > http://packages.debian.org/search?searchon=contents&keywords=atlas&mode=path&suite=unstable&arch=arm
>
> > So what would be the best idea to get blitz++ into testing?
> > Did I missed something?
Build-depend on refblas3 and lapack like the following:
refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev
ATLAS provides interfaces according to the BLAS standard, so refblas and
lapack are drop-in replacements[1] (also much slower, but that's not the
point: on more common architectures, people might have local faster
libraries that they might then use instead of the libraries in Debian).
Directly depending just on ATLAS is usually not what you want.
> I don't understand why atlas3 has such non-standard dev package handling,
Its build system is anything but standard and you normally *don't want*
it at build time.
> Once this is implemented, you can ask the maintainers of
> Packages-arch-specific to mark your package as "not for arm" as seen by the
> buildds, and ask the ftp team to remove the arm binary from unstable.
I think that's unneccessary, unless there's something in the blitz++
library that prevents it from building on ARM.
[1] Actually, it's the other way round: ATLAS should be a drop-in for
refblas and lapack.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
