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

Re: Gpiv bug #529994 repair



On Tue, 2009-08-04 at 08:04 +0200, Siggy Brentrup wrote:
> Hi Gerber,

> On Mon, Aug 03, 2009 at 14:43 +0200, you wrote:
> > Thanks very much! Its not very big. To give some idea, after building it
> > will result in:
> > 1.5M	0.6.1-2/gpiv-mpi_0.6.1-2_i386.deb
> > 12K	0.6.1-2/gpiv_0.6.1-2.diff.gz
> > 4.0K	0.6.1-2/gpiv_0.6.1-2.dsc
> > 4.0K	0.6.1-2/gpiv_0.6.1-2_i386.changes
> > 1.5M	0.6.1-2/gpiv_0.6.1-2_i386.deb
> > 1.7M	0.6.1-2/gpiv_0.6.1.orig.tar.gz
> > 
> > But it has quite some dependancies as it concerns a GUI program using
> > Gnome dev packages:
> > http://packages.debian.org/sid/gpiv
> 
> These dependencies disqualify your package for my box.  The machine is
> that slow and low-memory (64M) it will newer run Gnome or KDE, I'm even
> thinking of removing Xfce in favor of simple icewm.
> 
> Nevertheless I looked at your FTBFS bug and it's quite clear what you
> did wrong.  Look at the long description of mpi-default-dev:
> it states a depency on OpenMPI *on platforms where it exists*
> LAM otherwise.  mips(el)? architectures don't have OpenMPI.
> I guess you will have to pull in the LAM stuff explicitely to
> build successfully on mipsen.

I understood that the intention of mpi-default is to avoid specifying
explicitly openmpi or lam (or mpich) in the dependancy list as it just
picks the one that is available. I tested on my i386 box by only
installing openmpi or only lam, which seems to work fine in both cases.
So, if lam is available on mips, it just should build now after I
repaired the bug. (Previously the mpi.h was pointed explicitely to
mpi/mpi.h. By adjusting "configure" that uses "acx_mpi.m4" now, same as
in libgpiv-mpi3 and gpivtools-mpi, I supose it should build fine now as
well.)
I am intersted to see the pbuilder log from a mips(el) box. If your box
is too small, is there anybody else on this list who can do this for me?

Gerber

> 
> HTH
>   Siggy


Reply to: