Re: mpich C++ transition status

[Steve Langasek]

On Tue, Oct 25, 2005 at 10:08:52AM +0200, Rafael Laboissiere wrote:
> * Steve Langasek <[EMAIL PROTECTED]> [2005-10-24 23:59]:

> > On Mon, Oct 24, 2005 at 01:32:19PM +0200, Rafael Laboissiere wrote:
> > > but shouldn't octave-forge and octaviz be included in the list above?  
> > > These
> > > packages are not currently in testing.

> > Because they're not in testing, they don't affect whether the other
> > packages can be updated in testing.

> This means that once octave2.1 enters testing, both octaviz and octave-forge
> will be automatically promoted?  Or will a hint be needed?

They'll re-enter testing automatically, as long as they meet the other
criteria for testing propagation at the time (binaries in sync, aged long
enough in unstable).  So unless they're reuploaded in the next couple of
days, they should go in at the same time as the rest.

> > Anyway, it does look like everything's ready to go as soon as rmpi gets
> > built on hppa -- which should happen soon enough now that r-base has
> > successfully built there.

> I am holding my breath...  If you do not want to lose a DD by asphyxiation,
> please, go fast! :-)

rmpi has now built on hppa, so I think we're in really good shape.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Rafael Laboissiere]

* Steve Langasek <[EMAIL PROTECTED]> [2005-10-24 23:59]:

> On Mon, Oct 24, 2005 at 01:32:19PM +0200, Rafael Laboissiere wrote:
> > but shouldn't octave-forge and octaviz be included in the list above?  These
> > packages are not currently in testing.
> 
> Because they're not in testing, they don't affect whether the other
> packages can be updated in testing.

This means that once octave2.1 enters testing, both octaviz and octave-forge
will be automatically promoted?  Or will a hint be needed?

> Anyway, it does look like everything's ready to go as soon as rmpi gets
> built on hppa -- which should happen soon enough now that r-base has
> successfully built there.

I am holding my breath...  If you do not want to lose a DD by asphyxiation,
please, go fast! :-)

-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Mon, Oct 24, 2005 at 01:32:19PM +0200, Rafael Laboissiere wrote:
> * Russ Allbery <[EMAIL PROTECTED]> [2005-10-11 19:22]:

> > Here is the current status of the mpich/hdf5/lam migration.

> > The following are uploaded, but some have build problems:

> > Source: blacs-mpi
> > Source: hdf5
> > Source: illuminator
> > Source: lam
> > Source: mpb
> > Source: mpich
> > Source: netpipe
> > Source: octave2.1
> > Source: petsc
> > Source: plplot
> > Source: pytables
> > Source: rmpi
> > Source: scalapack
> > Source: semidef-oct
> > Source: tessa
> > Source: xmpi
> > Source: octave-gpc (contrib)
> > Source: parmetis (non-free)

> I guess we are getting quite close now (only rmpi on hppa is blocking now)
> but shouldn't octave-forge and octaviz be included in the list above?  These
> packages are not currently in testing.

Because they're not in testing, they don't affect whether the other packages
can be updated in testing.

Anyway, it does look like everything's ready to go as soon as rmpi gets
built on hppa -- which should happen soon enough now that r-base has
successfully built there.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

(Please note that I'm currently on vacation and won't have Internet access
for another week in about 15 minutes.  Just checking in on things while
I'm gone.)

Rafael Laboissiere <[EMAIL PROTECTED]> writes:

> I guess we are getting quite close now (only rmpi on hppa is blocking
> now) but shouldn't octave-forge and octaviz be included in the list
> above?  These packages are not currently in testing.

If the packages aren't currently in testing, we don't have to pay
attention to them for the purposes of this transition.  They'll migrate
into testing on either the same run or the next run after everything else
goes, and won't hold anything up if they're not ready.

We really only have to worry about packages that would become
uninstallable if mpich and friends went into testing without being
accompanied by an update of that package (and then, as a second pass,
worry about anything that now FTBFS due to the update, but given the
amount of stuff that's moving, that will be a second pass).

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Rafael Laboissiere]

* Russ Allbery <[EMAIL PROTECTED]> [2005-10-11 19:22]:

> Here is the current status of the mpich/hdf5/lam migration.
> 
> The following are uploaded, but some have build problems:
> 
> Source: blacs-mpi
> Source: hdf5
> Source: illuminator
> Source: lam
> Source: mpb
> Source: mpich
> Source: netpipe
> Source: octave2.1
> Source: petsc
> Source: plplot
> Source: pytables
> Source: rmpi
> Source: scalapack
> Source: semidef-oct
> Source: tessa
> Source: xmpi
> Source: octave-gpc (contrib)
> Source: parmetis (non-free)

I guess we are getting quite close now (only rmpi on hppa is blocking now)
but shouldn't octave-forge and octaviz be included in the list above?  These
packages are not currently in testing.
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Thu, Oct 20, 2005 at 10:32:09AM +0200, Rafael Laboissiere wrote:
> * Steve Langasek <[EMAIL PROTECTED]> [2005-10-05 01:28]:

> > > octave-gpc needs a requeue (and I think that's all) on alpha and
> > > mips, as it couldn't find libgpcl-dev and that package now appears to
> > > be available. I'm not sure what's going on with it on ia64; it
> > > installs libgpcl-dev and then can't find the header file from that
> > > package.  Maybe (he says hopefully) a rebuild will help there too?
> > > Should I mail the arch addresses @buildd.debian.org about those two
> > > requeues?

> > Actually, libgpcl-dev has been in the archive for alpha and mips, at
> > the same version, since before sarge's release.  I think the issue is
> > simply that the autobuilders aren't configured to draw
> > build-dependencies from non-free; I've just checked with Ryan Murray,
> > and he confirms this is a policy decision, not a bug.  So someone will
> > have to hand-build octave-gpc on alpha and mips (and possibly the
> > others).

> Would it help if octave-gpc goes into non-free?  

Not particularly; non-free doesn't get autobuilt any more reliably than
contrib does.  There are unofficial autobuilders available for non-free in
particular, but I don't know of any policy that would prevent them also
building contrib packages.

Anyway, a bigger issue is that libgpcl-dev is broken on alpha and ia64; bug
filed about that.

> BTW, is there anything in the Policy that prevents a package in contrib to
> build-depend on a package in non-free?

Nope, just practical considerations that prevent this from working today on
the buildds.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Rafael Laboissiere]

* Steve Langasek <[EMAIL PROTECTED]> [2005-10-05 01:28]:

> > octave-gpc needs a requeue (and I think that's all) on alpha and
> > mips, as it couldn't find libgpcl-dev and that package now appears to
> > be available. I'm not sure what's going on with it on ia64; it
> > installs libgpcl-dev and then can't find the header file from that
> > package.  Maybe (he says hopefully) a rebuild will help there too?
> > Should I mail the arch addresses @buildd.debian.org about those two
> > requeues?
> 
> Actually, libgpcl-dev has been in the archive for alpha and mips, at
> the same version, since before sarge's release.  I think the issue is
> simply that the autobuilders aren't configured to draw
> build-dependencies from non-free; I've just checked with Ryan Murray,
> and he confirms this is a policy decision, not a bug.  So someone will
> have to hand-build octave-gpc on alpha and mips (and possibly the
> others).

Would it help if octave-gpc goes into non-free?  

BTW, is there anything in the Policy that prevents a package in contrib to
build-depend on a package in non-free?
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steffen Moeller]

Dear Steve,

the package was ready and in place but the URL wrong, the debian
subdir was missing
> > http://bioinformatics.pzr.uni-rostock.de/~moeller/clustalw-mpi
http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/clustalw-mpi/

> I am happy to sponsor an upload of this package for you if you want, but I
> hesitated because you said you were considering asking for the package's
> removal.  There is nothing urgent, since clustalw-mpi has already been
> removed from testing as mentioned in my previous mail and no longer blocks
> the transition; the package will just be absent from testing until it is
> rebuilt.
 
> Hmm, I guess you still haven't published your package at the URL you
> mentioned, so there's no reason for me to worry about it right now anyway
> :-)

Please be so kind to sponsor it for me. I am still somewhat in love
with it and let us hope that the parental clustalw makes it license a
bit more open to industry in near future.

Best regards

Steffen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

Hi Steffen,

On Wed, Oct 12, 2005 at 01:17:07PM +0200, Steffen Moeller wrote:
> On Wed, Oct 12, 2005 at 02:08:21AM -0700, Steve Langasek wrote:
> > On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> > > Here is the current status of the mpich/hdf5/lam migration.

> > > Only one package still needs an upload:

> > > Source: clustalw-mpi (non-free)

> > FWIW, clustalw-mpi has now been removed from testing due to the RC bug you
> > filed on it previously.  The package can of course get back into testing
> > once it's been rebuilt for the transition, but I don't intend to let the
> > transition be held up for a single non-free package.

> I apologise for not having been more reactive. I am preparing an updated
> version at the moment and will place it at
> http://bioinformatics.pzr.uni-rostock.de/~moeller/clustalw-mpi
> since I understood now that it is urgent. I cannot upload the package
> myself since I am not accepted as a developer yet.

> The package is non-free and hence the uploading of the new version
> implies it being rebuild on several platforms. Popcon knows only about a
> disappointing 7 installations, some of which are mine, hence I am
> considering to ask to remove the package from the distribution.

I am happy to sponsor an upload of this package for you if you want, but I
hesitated because you said you were considering asking for the package's
removal.  There is nothing urgent, since clustalw-mpi has already been
removed from testing as mentioned in my previous mail and no longer blocks
the transition; the package will just be absent from testing until it is
rebuilt.

Hmm, I guess you still haven't published your package at the URL you
mentioned, so there's no reason for me to worry about it right now anyway
:-)

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Steve Langasek]

On Wed, Oct 12, 2005 at 01:44:22AM -0700, Steve Langasek wrote:

> > >> scalapack failed on powerpc with:

> > >> /usr/bin/ld: 
> > >> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> > >>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> > >> /usr/bin/ld: final link failed: Nonrepresentable section on output

> > >> Does this ring a bell with anyone?  That looks like a gcc issue, not a
> > >> problem with the package.  It's also in dep-wait on arm waiting for
> > >> libf2c2.

> > I've now seen this problem elsewhere, and it's a problem with binutils on
> > powerpc.  krb5 appears to also be affected.  See Bug#329686 for more
> > details.  Rebuilding the affected library from source should fix the
> > problem.

> > I'm not sure the right approach to take here.  A new libf2c2 build on
> > powerpc with the current binutils will fix the problem; should I file a
> > bug against libf2c2 asking for a new sourceful upload to unstable, or is
> > this the place for a porter binary NMU?  I never entirely understood how
> > those are supposed to work and when they are appropriate.

> I've requested a binNMU of libf2c2 for powerpc; scalapack will be retried
> automatically once the libf2c2 update is in the archive, so this should tell
> us pretty quickly if this fixes the bug.  If so, we can get a binNMU of krb5
> the same way.

And the rebuild of scalapack against the binNMU'ed libf2c2 still fails --
now with the same error as on arm.  So this now falls under bug #332955,
which probably would have fixed the powerpc problem anyway by way of
removing libf2c2 from the equation...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Steffen Moeller]

On Wed, Oct 12, 2005 at 02:08:21AM -0700, Steve Langasek wrote:
> On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> > Here is the current status of the mpich/hdf5/lam migration.
> 
> > Only one package still needs an upload:
> 
> > Source: clustalw-mpi (non-free)
> 
> FWIW, clustalw-mpi has now been removed from testing due to the RC bug you
> filed on it previously.  The package can of course get back into testing
> once it's been rebuilt for the transition, but I don't intend to let the
> transition be held up for a single non-free package.

Dear Russ and dear Steve,

I apologise for not having been more reactive. I am preparing an updated
version at the moment and will place it at
http://bioinformatics.pzr.uni-rostock.de/~moeller/clustalw-mpi
since I understood now that it is urgent. I cannot upload the package
myself since I am not accepted as a developer yet.

The package is non-free and hence the uploading of the new version
implies it being rebuild on several platforms. Popcon knows only about a
disappointing 7 installations, some of which are mine, hence I am
considering to ask to remove the package from the distribution.

No novel upstream version of the package is yet available which IMHO would
justify to bother my sponsor about an upload. I do not want to ask my
sponsor to perform regular maintenance.

Version 1.13-3 will be at the prior mentioned location later today.

Kind regards

Steffen MÃller


> 
> >  * pytables needs a build on alpha and rmpi and scalapack need builds on
> >arm.
> 
> pytables is already building on arm (now that there's a python2.3-numarray
> package in the archive which doesn't contain an empty .so).  rmpi and
> scalapack needed to be given back on arm, due to a buildd burp; this has now
> been done.
> 
> >  * octave-gpc needs personal attention to get builds for alpha, ia64, and
> >mips (and m68k) due to being in non-free and having non-free
> >dependencies.
> 
> This will be a candidate for removal from testing if these builds still
> aren't done when the rest of the packages are ready to go in.
> 
> Cheers,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Going through the build problems on that list:

Oh, sorry, and parmetis (non-free) needs a build on mips.  I keep
forgetting that one because it doesn't show up on the buildd report for
some reason, only in the update-excuses output.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> Here is the current status of the mpich/hdf5/lam migration.

> Only one package still needs an upload:

> Source: clustalw-mpi (non-free)

FWIW, clustalw-mpi has now been removed from testing due to the RC bug you
filed on it previously.  The package can of course get back into testing
once it's been rebuilt for the transition, but I don't intend to let the
transition be held up for a single non-free package.

>  * pytables needs a build on alpha and rmpi and scalapack need builds on
>arm.

pytables is already building on arm (now that there's a python2.3-numarray
package in the archive which doesn't contain an empty .so).  rmpi and
scalapack needed to be given back on arm, due to a buildd burp; this has now
been done.

>  * octave-gpc needs personal attention to get builds for alpha, ia64, and
>mips (and m68k) due to being in non-free and having non-free
>dependencies.

This will be a candidate for removal from testing if these builds still
aren't done when the rest of the packages are ready to go in.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

severity 333462 serious
thanks

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Oct 11, 2005 at 06:55:15PM -0700, Russ Allbery wrote:

>> I've filed a bug against r-base for this.  I'm going to file it at
>> severity: important since I don't want the bug itself to block
>> migration if hppa gets built properly, but if that's not correct and it
>> should be upgraded, please feel free to either do so or ask me to do
>> so.

> This really ought to be severity: serious; the package isn't going to
> get built without someone taking action, so I wouldn't worry about it
> getting fixed without the bug also being cleared.

Sure thing.

A new version of octave2.1 has been uploaded to fix the build dependencies
for m68k, btw.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Tue, Oct 11, 2005 at 06:55:15PM -0700, Russ Allbery wrote:
> Following up on the issues from my previous note that still exist.  Sorry
> that I hadn't given this attention sooner; I've been a bit buried
> preparing for vacation.

No worries. :)

> Steve Langasek <[EMAIL PROTECTED]> writes:
> > If the package previously built without trouble on hppa, it tends to
> > suggest the package has gotten itself into an infinite loop of some
> > kind, or else that a new version is substantially slower than previous
> > versions for some unknown reason.  It will almost certainly require
> > coordination between the maintainer and the buildd admin to figure out.

> I've filed a bug against r-base for this.  I'm going to file it at
> severity: important since I don't want the bug itself to block migration
> if hppa gets built properly, but if that's not correct and it should be
> upgraded, please feel free to either do so or ask me to do so.

This really ought to be severity: serious; the package isn't going to get
built without someone taking action, so I wouldn't worry about it getting
fixed without the bug also being cleared.

> >> scalapack failed on powerpc with:

> >> /usr/bin/ld: 
> >> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> >>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> >> /usr/bin/ld: final link failed: Nonrepresentable section on output

> >> Does this ring a bell with anyone?  That looks like a gcc issue, not a
> >> problem with the package.  It's also in dep-wait on arm waiting for
> >> libf2c2.

> I've now seen this problem elsewhere, and it's a problem with binutils on
> powerpc.  krb5 appears to also be affected.  See Bug#329686 for more
> details.  Rebuilding the affected library from source should fix the
> problem.

> I'm not sure the right approach to take here.  A new libf2c2 build on
> powerpc with the current binutils will fix the problem; should I file a
> bug against libf2c2 asking for a new sourceful upload to unstable, or is
> this the place for a porter binary NMU?  I never entirely understood how
> those are supposed to work and when they are appropriate.

I've requested a binNMU of libf2c2 for powerpc; scalapack will be retried
automatically once the libf2c2 update is in the archive, so this should tell
us pretty quickly if this fixes the bug.  If so, we can get a binNMU of krb5
the same way.

> > The removal will be semi-automatic once plplot has built on m68k, but
> > that won't happen until octave2.1 is also available on m68k.  But
> > octave2.1 build-depends on gfortran, which is not available on m68k --
> > and not because the package hasn't built, because the package source is
> > gcc-defaults.  That looks like someone should file a bug against
> > octave2.1, asking it to build-depend again on fort77 on m68k as previous
> > versions did.

> Bug filed.

Looks good, thanks.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

Here is the current status of the mpich/hdf5/lam migration.

Only one package still needs an upload:

Source: clustalw-mpi (non-free)

I have cc'd the maintainer on this message.  If anyone else has a chance
to do an NMU, please do so, unless the maintainer speaks up and asks to
handle it.  The package will need builds on i386 and mips.

The following are uploaded, but some have build problems:

Source: blacs-mpi
Source: hdf5
Source: illuminator
Source: lam
Source: mpb
Source: mpich
Source: netpipe
Source: octave2.1
Source: petsc
Source: plplot
Source: pytables
Source: rmpi
Source: scalapack
Source: semidef-oct
Source: tessa
Source: xmpi
Source: octave-gpc (contrib)
Source: parmetis (non-free)

To get a fairly complete build picture of this migration, see:

http://people.debian.org/~igloo/status.php?email=&packages=clustalw-mpi+blacs-mpi+hdf5+illuminator+lam+mpb+mpich+netpipe+octave2.1+petsc+plplot+pytables+rmpi+scalapack+semidef-oct+tessa+xmpi+octave-gpc+parmetis&arches=alpha+amd64+arm+hppa+i386+ia64+mips+mipsel+powerpc+s390+sparc

Note that m68k is being ignored for this transition.

Going through the build problems on that list:

 * mpb is in dep-wait on arm for atlas3, but that's okay; neither atlas3
   nor mpb have ever built on arm.  This can be ignored for right now.

 * pytables needs a build on alpha and rmpi and scalapack need builds on
   arm.

 * rmpi is waiting for r-base on hppa.  r-base needs to have the test
   suite disabled on hppa, and the maintainer requests a porter NMU.  See
   .

 * scalapack failed to build on powerpc due to (we think) a bad powerpc
   build of libf2c2.  Bug (just) filed against libf2c2 to track this
   issue.

 * octave-gpc needs personal attention to get builds for alpha, ia64, and
   mips (and m68k) due to being in non-free and having non-free
   dependencies.

finally, the following packages need a rebuild but aren't in testing, so
we can ignore them for the time being:

Source: kmatplot
Source: r-cran-hdf5
Source: statdataml
Source: warped

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Russ Allbery]

Following up on the issues from my previous note that still exist.  Sorry
that I hadn't given this attention sooner; I've been a bit buried
preparing for vacation.

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote:

>> rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and
>> in dep-wait on hppa waiting for r-base.  r-base failed on hppa with an
>> odd error:

>> running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated
>> make[2]: *** [test-all-basics] Terminated
>> make[3]: *** [test-Examples] Terminated
>> semop(2): encountered an error: Invalid argument
>> make: *** [check-stamp] Terminated
>> make[4]: *** [test-Examples-Base] Error 1
>> Build killed with signal 15 after 150 minutes of inactivity

>> Not really sure what to do with that problem; it smells a little like a
>> buildd issue rather than a problem with the package?

> If the package previously built without trouble on hppa, it tends to
> suggest the package has gotten itself into an infinite loop of some
> kind, or else that a new version is substantially slower than previous
> versions for some unknown reason.  It will almost certainly require
> coordination between the maintainer and the buildd admin to figure out.

I've filed a bug against r-base for this.  I'm going to file it at
severity: important since I don't want the bug itself to block migration
if hppa gets built properly, but if that's not correct and it should be
upgraded, please feel free to either do so or ask me to do so.

>> scalapack failed on powerpc with:

>> /usr/bin/ld: 
>> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
>>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
>> /usr/bin/ld: final link failed: Nonrepresentable section on output

>> Does this ring a bell with anyone?  That looks like a gcc issue, not a
>> problem with the package.  It's also in dep-wait on arm waiting for
>> libf2c2.

> My first guess was that scalapack was trying to link a shared library
> against non-PIC code, but that doesn't seem to be the case.  It may be a
> problem with gcc, but it may be a once-removed problem with an *old*
> version of gcc that requires rebuilding libf2c to fix it.  Dunno,
> someone will need to poke at this (maybe debian-powerpc?).

I've now seen this problem elsewhere, and it's a problem with binutils on
powerpc.  krb5 appears to also be affected.  See Bug#329686 for more
details.  Rebuilding the affected library from source should fix the
problem.

I'm not sure the right approach to take here.  A new libf2c2 build on
powerpc with the current binutils will fix the problem; should I file a
bug against libf2c2 asking for a new sourceful upload to unstable, or is
this the place for a porter binary NMU?  I never entirely understood how
those are supposed to work and when they are appropriate.

> The removal will be semi-automatic once plplot has built on m68k, but
> that won't happen until octave2.1 is also available on m68k.  But
> octave2.1 build-depends on gfortran, which is not available on m68k --
> and not because the package hasn't built, because the package source is
> gcc-defaults.  That looks like someone should file a bug against
> octave2.1, asking it to build-depend again on fort77 on m68k as previous
> versions did.

Bug filed.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Wed, Oct 05, 2005 at 01:25:12PM +0200, Frank Lichtenheld wrote:
> On Wed, Oct 05, 2005 at 01:28:34AM -0700, Steve Langasek wrote:
> > On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote:
> > > scalapack failed on powerpc with:

> > > /usr/bin/ld: 
> > > /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> > >  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> > > /usr/bin/ld: final link failed: Nonrepresentable section on output

> > > Does this ring a bell with anyone?  That looks like a gcc issue, not a
> > > problem with the package.  It's also in dep-wait on arm waiting for
> > > libf2c2.

> > My first guess was that scalapack was trying to link a shared library
> > against non-PIC code, but that doesn't seem to be the case.  It may be a
> > problem with gcc, but it may be a once-removed problem with an *old* version
> > of gcc that requires rebuilding libf2c to fix it.  Dunno, someone will need
> > to poke at this (maybe debian-powerpc?).

> Hmm, still fails to build in a uptodate chroot:

Is this also true if you rebuild libf2c2 with the current toolchain?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Frank Lichtenheld]

On Wed, Oct 05, 2005 at 01:28:34AM -0700, Steve Langasek wrote:
> On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote:
> > scalapack failed on powerpc with:
> 
> > /usr/bin/ld: 
> > /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> >  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> > /usr/bin/ld: final link failed: Nonrepresentable section on output
> 
> > Does this ring a bell with anyone?  That looks like a gcc issue, not a
> > problem with the package.  It's also in dep-wait on arm waiting for
> > libf2c2.
> 
> My first guess was that scalapack was trying to link a shared library
> against non-PIC code, but that doesn't seem to be the case.  It may be a
> problem with gcc, but it may be a once-removed problem with an *old* version
> of gcc that requires rebuilding libf2c to fix it.  Dunno, someone will need
> to poke at this (maybe debian-powerpc?).

Hmm, still fails to build in a uptodate chroot:
make[2]: Entering directory `/tmp/buildd/scalapack-1.7/REDIST/TESTING'
gcc -c -Wall  -O6 -funroll-all-loops -ffast-math -Df77IsF2C -DNO_IEEE
-DUsingMpiBlacs pigemrdrv.c
pigemrdrv.c: In function 'getparam':
pigemrdrv.c:191: warning: unused variable 'i'
pigemrdrv.c: In function 'main':
pigemrdrv.c:272: warning: implicit declaration of function 'MPI_Init'
pigemrdrv.c:315: warning: unused variable 'd'
pigemrdrv.c:315: warning: unused variable 'u'
pigemrdrv.c:469: warning: suggest explicit braces to avoid ambiguous 'else'
pigemrdrv.c:251: warning: 'fp' may be used uninitialized in this function
pigemrdrv.c:261: warning: 'blocksize0' may be used uninitialized in this 
function
gcc  -o /tmp/buildd/scalapack-1.7/TESTING/xigemr pigemrdrv.o -L
/tmp/buildd/scalapack-1.7 -lscalapack-lam -lblacsCinit-lam -lblacs-lam 
-lblacsCinit-lam -lmpi -llapack -lblas -lf2c -lm
/usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.so: undefined 
reference to `MAIN__'
collect2: ld returned 1 exit status
make[2]: *** [/tmp/buildd/scalapack-1.7/TESTING/xigemr] Error 1
make[2]: Leaving directory `/tmp/buildd/scalapack-1.7/REDIST/TESTING'
make[1]: *** [redistexe] Error 2
make[1]: Leaving directory `/tmp/buildd/scalapack-1.7'
make: *** [build-stamp-lam] Error 2

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Things are far enough along that I've gone ahead and added a preliminary
> > hint for lam/mpich, visible at
> > .  This will let us
> > get feedback via
> > http://ftp-master.debian.org/testing/update_output.txt.gz in subsequent
> > britney runs, so we can see at a glance what issues are still
> > outstanding, and also catch any problems that weren't visible to the
> > naked eye.

> I'm not really sure how to read the britney output.  I think that this is
> the relevant failure:

> now: 157+0: a-13:a-14:h-13:i-18:i-14:m-17:m-16:m-13:p-14:s-15:s-10
> * alpha: blacs-mpich-dev, blacs-mpich-test, blacs1-mpich, 
> libhdf5-mpich-1.6.2-0, libhdf5-mpich-dev, mpb-mpi, netpipe-mpich, 
> scalapack-mpich-dev, scalapack-mpich-test, scalapack1-mpich
> [...]

> FAILED

> but that would seem to imply that it's still exploding on all the
> blacs-mpi stuff, which is part of the hint?  Or maybe it wasn't part of
> the hint at the last britney run and you just added that?

It's not all that useful of a hint yet, because lam waits on gcc-4.0; I had
split the hint into two parts to be able to get a partial look at things.
The hint will start to give us more useful information once gcc-4.0 is
closer to being sorted out.

> Anyway, the whole thing won't go without new versions of:

> Source: netpipe
> Source: xmpi
> Source: clustalw-mpi (non-free)

> at least, even with more hint refinement.  Maybe we're getting towards
> time for NMUs of those remaining packages?

Yes, that would be a good idea.


> rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and in
> dep-wait on hppa waiting for r-base.  r-base failed on hppa with an odd
> error:

> running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated
> make[2]: *** [test-all-basics] Terminated
> make[3]: *** [test-Examples] Terminated
> semop(2): encountered an error: Invalid argument
> make: *** [check-stamp] Terminated
> make[4]: *** [test-Examples-Base] Error 1
> Build killed with signal 15 after 150 minutes of inactivity

> Not really sure what to do with that problem; it smells a little like a
> buildd issue rather than a problem with the package?

If the package previously built without trouble on hppa, it tends to suggest
the package has gotten itself into an infinite loop of some kind, or else
that a new version is substantially slower than previous versions for some
unknown reason.  It will almost certainly require coordination between the
maintainer and the buildd admin to figure out.

Note that the last version of r-base which succeeded only took 45 minutes to
build; going from a 45-minute built to 150 minutes of inactivity is usually
a sign of a package bug.

> scalapack failed on powerpc with:

> /usr/bin/ld: 
> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> /usr/bin/ld: final link failed: Nonrepresentable section on output

> Does this ring a bell with anyone?  That looks like a gcc issue, not a
> problem with the package.  It's also in dep-wait on arm waiting for
> libf2c2.

My first guess was that scalapack was trying to link a shared library
against non-PIC code, but that doesn't seem to be the case.  It may be a
problem with gcc, but it may be a once-removed problem with an *old* version
of gcc that requires rebuilding libf2c to fix it.  Dunno, someone will need
to poke at this (maybe debian-powerpc?).

> octave-gpc needs a requeue (and I think that's all) on alpha and mips, as
> it couldn't find libgpcl-dev and that package now appears to be available.
> I'm not sure what's going on with it on ia64; it installs libgpcl-dev and
> then can't find the header file from that package.  Maybe (he says
> hopefully) a rebuild will help there too?  Should I mail the arch
> addresses @buildd.debian.org about those two requeues?

Actually, libgpcl-dev has been in the archive for alpha and mips, at the
same version, since before sarge's release.  I think the issue is simply
that the autobuilders aren't configured to draw build-dependencies from
non-free; I've just checked with Ryan Murray, and he confirms this is a
policy decision, not a bug.  So someone will have to hand-build octave-gpc
on alpha and mips (and possibly the others).

> semidef-oct is now fine, as is parmetis.

I still show parmetis as out-of-date on mips.  This seems to be a
wanna-build bug, since the package is listed in state 'Installed' even
though there is a newer source version available.  The package is in
non-free anyway, so it'll need the same treatment as octave-gpc regardless.

> For the removal of plplot9-driver-gnome, should I submit a bug against
> ftp.debian.org, or leave that for the package maintainer to do?

The removal will be semi-automatic once plplot has b

Re: mpich C++ transition status

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Things are far enough along that I've gone ahead and added a preliminary
> hint for lam/mpich, visible at
> .  This will let us
> get feedback via
> http://ftp-master.debian.org/testing/update_output.txt.gz in subsequent
> britney runs, so we can see at a glance what issues are still
> outstanding, and also catch any problems that weren't visible to the
> naked eye.

I'm not really sure how to read the britney output.  I think that this is
the relevant failure:

now: 157+0: a-13:a-14:h-13:i-18:i-14:m-17:m-16:m-13:p-14:s-15:s-10
* alpha: blacs-mpich-dev, blacs-mpich-test, blacs1-mpich, 
libhdf5-mpich-1.6.2-0, libhdf5-mpich-dev, mpb-mpi, netpipe-mpich, 
scalapack-mpich-dev, scalapack-mpich-test, scalapack1-mpich
[...]

FAILED

but that would seem to imply that it's still exploding on all the
blacs-mpi stuff, which is part of the hint?  Or maybe it wasn't part of
the hint at the last britney run and you just added that?

Anyway, the whole thing won't go without new versions of:

Source: netpipe
Source: xmpi
Source: clustalw-mpi (non-free)

at least, even with more hint refinement.  Maybe we're getting towards
time for NMUs of those remaining packages?

> Since m68k is still not catching up very well, I'm forcing consideration
> of all the related packages where m68k is the only architecture we're
> missing.  From your list, there are still the following packages in need
> of builds/uploads on other architectures, according to the output of the
> last britney run: pytables, rmpi, scalapack, semidef-oct, octave-gpc,
> and parmetis.  In addition, plplot needs an ftp-master to remove the
> plplot9-driver-gnome binaries from unstable.

Looking through these:

pytables has failed on Alpha.  The error message is:

/usr/bin/python2.3 setup.py build
Can't find a local numarray Python installation.
Please, read carefully the README and remember
that PyTables needs the numarray package to
compile and run.

but python2.3-numarray was installed.  I'm mystified on this one.  I'll
submit a bug against pytables in the hope that the maintainer can take a
look at it; it may need to get reassigned to python-numarray.

rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and in
dep-wait on hppa waiting for r-base.  r-base failed on hppa with an odd
error:

running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated
make[2]: *** [test-all-basics] Terminated
make[3]: *** [test-Examples] Terminated
semop(2): encountered an error: Invalid argument
make: *** [check-stamp] Terminated
make[4]: *** [test-Examples-Base] Error 1
Build killed with signal 15 after 150 minutes of inactivity

Not really sure what to do with that problem; it smells a little like a
buildd issue rather than a problem with the package?

scalapack failed on powerpc with:

/usr/bin/ld: 
/usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
 unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
/usr/bin/ld: final link failed: Nonrepresentable section on output

Does this ring a bell with anyone?  That looks like a gcc issue, not a
problem with the package.  It's also in dep-wait on arm waiting for
libf2c2.

octave-gpc needs a requeue (and I think that's all) on alpha and mips, as
it couldn't find libgpcl-dev and that package now appears to be available.
I'm not sure what's going on with it on ia64; it installs libgpcl-dev and
then can't find the header file from that package.  Maybe (he says
hopefully) a rebuild will help there too?  Should I mail the arch
addresses @buildd.debian.org about those two requeues?

semidef-oct is now fine, as is parmetis.

For the removal of plplot9-driver-gnome, should I submit a bug against
ftp.debian.org, or leave that for the package maintainer to do?

> If you aren't already familiar with it,
> http://people.debian.org/~igloo/status.php is a useful resource for
> getting an at-a-glance view of the build status of multiple packages
> across all architectures.  You may want to load this list of packages up
> into that page, and see if there are any build failures that might
> require additional hand-holding.

Very good idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Matthias Klose]

Steve Langasek writes:
> At any rate, pretty much all new package uploads right now are being blocked
> by gcc-4.0 -- I haven't looked, but the symptoms smell like a libgcc shlibs
> bump on hppa, or possibly on all archs.  So, back to working on that problem
> for a while...

new symbol in libstdc++6, gcc-4.0_4.0.2-2 should be a candidate for
testing.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

Russ,

On Fri, Sep 30, 2005 at 06:11:49PM -0700, Russ Allbery wrote:
> Here is the current status of the mpich/hdf5/lam migration.

> lam is currently building on m68k, after which point hdf5 needs to be
> requeued on m68k, and then once it builds various other packages will need
> requeues on m68k because they're blocked waiting for hdf5.

Great, thanks for sticking with this.

Things are far enough along that I've gone ahead and added a preliminary hint
for lam/mpich, visible at
.  This will let us get
feedback via http://ftp-master.debian.org/testing/update_output.txt.gz in
subsequent britney runs, so we can see at a glance what issues are still
outstanding, and also catch any problems that weren't visible to the naked
eye.

Since m68k is still not catching up very well, I'm forcing consideration of
all the related packages where m68k is the only architecture we're missing.
From your list, there are still the following packages in need of
builds/uploads on other architectures, according to the output of the last
britney run: pytables, rmpi, scalapack, semidef-oct, octave-gpc, and
parmetis.  In addition, plplot needs an ftp-master to remove the
plplot9-driver-gnome binaries from unstable.

If you aren't already familiar with it,
http://people.debian.org/~igloo/status.php is a useful resource for getting
an at-a-glance view of the build status of multiple packages across all
architectures.  You may want to load this list of packages up into that
page, and see if there are any build failures that might require additional
hand-holding.

At any rate, pretty much all new package uploads right now are being blocked
by gcc-4.0 -- I haven't looked, but the symptoms smell like a libgcc shlibs
bump on hppa, or possibly on all archs.  So, back to working on that problem
for a while...

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Frank Lichtenheld]

On Sat, Oct 01, 2005 at 10:02:13AM +0200, Rafael Laboissiere wrote:
> * Russ Allbery <[EMAIL PROTECTED]> [2005-09-30 18:11]:
> 
> > The following packages still need a new upload:
> > 
> > Source: r-cran-hdf5
> > Source: statdataml
> 
> Just to let you know:  I will orphan soon these two packages and will
> ultimately ask for removal from the archive.  This is under discussion in
> the pkg-octave-devel mailing list at Alioth.  I am in the middle of a trip
> now and will be only able to resume this action in one week or so.
> 
> For now, just ignore these two packages.

Which means removing them from testing. Have added a hint to that
effect.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Rafael Laboissiere]

* Russ Allbery <[EMAIL PROTECTED]> [2005-09-30 18:11]:

> The following packages still need a new upload:
> 
> Source: r-cran-hdf5
> Source: statdataml

Just to let you know:  I will orphan soon these two packages and will
ultimately ask for removal from the archive.  This is under discussion in
the pkg-octave-devel mailing list at Alioth.  I am in the middle of a trip
now and will be only able to resume this action in one week or so.

For now, just ignore these two packages.
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Russ Allbery]

Here is the current status of the mpich/hdf5/lam migration.

lam is currently building on m68k, after which point hdf5 needs to be
requeued on m68k, and then once it builds various other packages will need
requeues on m68k because they're blocked waiting for hdf5.

The following packages still need a new upload:

Source: netpipe
Source: r-cran-hdf5
Source: statdataml
Source: xmpi
Source: clustalw-mpi (non-free)

I'm cc'ing the maintainers of these packages; bugs have already been
filed, and I expect they all already know that this is an issue, but
better safe than sorry.

The following are done, but may not be built yet on all platforms:

Source: blacs-mpi
Source: hdf5
Source: illuminator
Source: lam
Source: mpb
Source: mpich
Source: octave2.1
Source: petsc
Source: plplot
Source: pytables
Source: rmpi
Source: scalapack
Source: semidef-oct
Source: tessa
Source: octave-gpc (contrib)
Source: parmetis (non-free)

The following packages need a rebuild but aren't in testing, so we can
ignore them for the time being:

Source: kmatplot
Source: warped

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Camm Maguire]

Thanks!  This is ready for next upload whenever that happens, already
had uploaded /u+x (which appears to be working).

Take care,

Andreas Metzler <[EMAIL PROTECTED]> writes:

> On 2005-09-26 Camm Maguire <[EMAIL PROTECTED]> wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> >> On Sat, Sep 24, 2005 at 02:32:56PM -0700, Russ Allbery wrote:
> >>> Russ Allbery <[EMAIL PROTECTED]> writes:
> [...] 
> >>> mkdir -p debian/tmp/usr/bin
> >>> cd $(dirname $(find -name lamclean -perm +u+x -type f 
> [...]
> 
> >> Yeah, that'll be that crazy upstream findutils change that breaks -perm
> >> +foo in the name of POSIX..  According to the thread on debian-devel, the
> >> new syntax is apparently -perm /foo. :P
> 
> > Lovely!  But I've just upgraded, and still can't get find locally
> > which follows this syntax.  Is this change final?
> 
> Short version: Use -perm -u+x
> Long version: /perm is iirc broken in 4.2.24, and +perm is broken both
> in 24 and 25, with 25 matching too little and 24 matching too much.
> #329358
>cu and- wondering how you could end up with .24 on a fresh
>installation -reas
> -- 
> "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
> fuhggvat qbja gur juveyvat tha.
> Neal Stephenson in "Snow Crash"
> 
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Andreas Metzler]

On 2005-09-26 Camm Maguire <[EMAIL PROTECTED]> wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
>> On Sat, Sep 24, 2005 at 02:32:56PM -0700, Russ Allbery wrote:
>>> Russ Allbery <[EMAIL PROTECTED]> writes:
[...] 
>>> mkdir -p debian/tmp/usr/bin
>>> cd $(dirname $(find -name lamclean -perm +u+x -type f 
[...]

>> Yeah, that'll be that crazy upstream findutils change that breaks -perm
>> +foo in the name of POSIX..  According to the thread on debian-devel, the
>> new syntax is apparently -perm /foo. :P

> Lovely!  But I've just upgraded, and still can't get find locally
> which follows this syntax.  Is this change final?

Short version: Use -perm -u+x
Long version: /perm is iirc broken in 4.2.24, and +perm is broken both
in 24 and 25, with 25 matching too little and 24 matching too much.
#329358
   cu and- wondering how you could end up with .24 on a fresh
   installation -reas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#330103: mpich C++ transition status

[Camm Maguire]

Greetings!

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Mon, Sep 26, 2005 at 12:55:14PM -0400, Camm Maguire wrote:
> > > > mkdir -p debian/tmp/usr/bin
> > > > cd $(dirname $(find -name lamclean -perm +u+x -type f |grep -v debian)) 
> > > > && mv -f lamclean lamclean.old && ( /usr/bin/make -n lamclean | awk 
> > > > '/mkdir/ {next} /libtool/ { gsub("[^ 
> > > > ]*liblam\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > > > -ldl"); gsub("[^ 
> > > > ]*libmpi\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > > > -ldl"); gsub(" lamclean "," 
> > > > '/build/buildd/lam-7.1.1/debian/tmp/usr/bin/lamclean' "); print}' | 
> > > > bash -x -e || (mv lamclean.old lamclean && false)) && mv lamclean.old 
> > > > lamclean
> > >  ^^
> 
> > > Yeah, that'll be that crazy upstream findutils change that breaks -perm
> > > +foo in the name of POSIX..  According to the thread on debian-devel, the
> > > new syntax is apparently -perm /foo. :P
> 
> > Lovely!  But I've just upgraded, and still can't get find locally
> > which follows this syntax.  Is this change final?
> 
> I don't understand.  You're saying that findutils on your system doesn't
> respect the -perm /u+x syntax?  What version of findutils do you have
> installed?
> 

Yes, fresh apt-get install this morning:

[EMAIL PROTECTED]:/fix/t1/camm/debian/lam/lam-7.1.1$ find -name lamclean -perm 
+u+x
./otb/lamclean
./otb/lamclean/lamclean
./debian/static/usr/lib/lam/bin/lamclean
./debian/shared/usr/lib/lam/bin/lamclean
./debian/lam-runtime/usr/bin/lamclean
[EMAIL PROTECTED]:/fix/t1/camm/debian/lam/lam-7.1.1$ find -name lamclean -perm 
/u+x
[EMAIL PROTECTED]:/fix/t1/camm/debian/lam/lam-7.1.1$ dpkg -l findutils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name  Version   Description
+++-=-=-==
ii  findutils 4.2.24-1  utilities for finding 
files--find, xargs, and locate
[EMAIL PROTECTED]:/fix/t1/camm/debian/lam/lam-7.1.1$ 

Take care,

> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Mon, Sep 26, 2005 at 12:55:14PM -0400, Camm Maguire wrote:
> > > mkdir -p debian/tmp/usr/bin
> > > cd $(dirname $(find -name lamclean -perm +u+x -type f |grep -v debian)) 
> > > && mv -f lamclean lamclean.old && ( /usr/bin/make -n lamclean | awk 
> > > '/mkdir/ {next} /libtool/ { gsub("[^ 
> > > ]*liblam\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > > -ldl"); gsub("[^ 
> > > ]*libmpi\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > > -ldl"); gsub(" lamclean "," 
> > > '/build/buildd/lam-7.1.1/debian/tmp/usr/bin/lamclean' "); print}' | bash 
> > > -x -e || (mv lamclean.old lamclean && false)) && mv lamclean.old lamclean
> >  ^^

> > Yeah, that'll be that crazy upstream findutils change that breaks -perm
> > +foo in the name of POSIX..  According to the thread on debian-devel, the
> > new syntax is apparently -perm /foo. :P

> Lovely!  But I've just upgraded, and still can't get find locally
> which follows this syntax.  Is this change final?

I don't understand.  You're saying that findutils on your system doesn't
respect the -perm /u+x syntax?  What version of findutils do you have
installed?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Camm Maguire]

Greetings!

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, Sep 24, 2005 at 02:32:56PM -0700, Russ Allbery wrote:
> > Russ Allbery <[EMAIL PROTECTED]> writes:
> 
> > > Also, hdf5 depends on lam, which also had to do its own transition, and
> > > that adds the following additional packages:
> 
> > > Package: libxmpi4
> > > Package: netpipe-lam
> > > Package: r-cran-rmpi
> > > Package: xmpi
> 
> > lam has now been uploaded with optimization lowered, which will hopefully
> > correct the problem with m68k, but it looks like the package is failing
> > on nearly all the buildds due to another problem:
> 
> > mkdir -p debian/tmp/usr/bin
> > cd $(dirname $(find -name lamclean -perm +u+x -type f |grep -v debian)) && 
> > mv -f lamclean lamclean.old && ( /usr/bin/make -n lamclean | awk '/mkdir/ 
> > {next} /libtool/ { gsub("[^ 
> > ]*liblam\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > -ldl"); gsub("[^ 
> > ]*libmpi\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> > -ldl"); gsub(" lamclean "," 
> > '/build/buildd/lam-7.1.1/debian/tmp/usr/bin/lamclean' "); print}' | bash -x 
> > -e || (mv lamclean.old lamclean && false)) && mv lamclean.old lamclean
>  ^^
> 
> Yeah, that'll be that crazy upstream findutils change that breaks -perm
> +foo in the name of POSIX..  According to the thread on debian-devel, the
> new syntax is apparently -perm /foo. :P
> 

Lovely!  But I've just upgraded, and still can't get find locally
which follows this syntax.  Is this change final?

Take care,

> > The hdf5 and mpich portions of the migration look to be in better shape,
> > although I'm going to take a more detailed look shortly.
> 
> Glad to hear it!
> 
> Thanks,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Sat, Sep 24, 2005 at 02:32:56PM -0700, Russ Allbery wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:

> > Also, hdf5 depends on lam, which also had to do its own transition, and
> > that adds the following additional packages:

> > Package: libxmpi4
> > Package: netpipe-lam
> > Package: r-cran-rmpi
> > Package: xmpi

> lam has now been uploaded with optimization lowered, which will hopefully
> correct the problem with m68k, but it looks like the package is failing
> on nearly all the buildds due to another problem:

> mkdir -p debian/tmp/usr/bin
> cd $(dirname $(find -name lamclean -perm +u+x -type f |grep -v debian)) && mv 
> -f lamclean lamclean.old && ( /usr/bin/make -n lamclean | awk '/mkdir/ {next} 
> /libtool/ { gsub("[^ 
> ]*liblam\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam -ldl"); 
> gsub("[^ ]*libmpi\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
> -ldl"); gsub(" lamclean "," 
> '/build/buildd/lam-7.1.1/debian/tmp/usr/bin/lamclean' "); print}' | bash -x 
> -e || (mv lamclean.old lamclean && false)) && mv lamclean.old lamclean
 ^^

Yeah, that'll be that crazy upstream findutils change that breaks -perm
+foo in the name of POSIX..  According to the thread on debian-devel, the
new syntax is apparently -perm /foo. :P

> The hdf5 and mpich portions of the migration look to be in better shape,
> although I'm going to take a more detailed look shortly.

Glad to hear it!

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Also, hdf5 depends on lam, which also had to do its own transition, and
> that adds the following additional packages:

> Package: libxmpi4
> Package: netpipe-lam
> Package: r-cran-rmpi
> Package: xmpi

lam has now been uploaded with optimization lowered, which will hopefully
correct the problem with m68k, but it looks like the package is failing
on nearly all the buildds due to another problem:

mkdir -p debian/tmp/usr/bin
cd $(dirname $(find -name lamclean -perm +u+x -type f |grep -v debian)) && mv 
-f lamclean lamclean.old && ( /usr/bin/make -n lamclean | awk '/mkdir/ {next} 
/libtool/ { gsub("[^ 
]*liblam\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam -ldl"); 
gsub("[^ ]*libmpi\\.la","-L'/build/buildd/lam-7.1.1/debian/tmp/usr/lib' -llam 
-ldl"); gsub(" lamclean "," 
'/build/buildd/lam-7.1.1/debian/tmp/usr/bin/lamclean' "); print}' | bash -x -e 
|| (mv lamclean.old lamclean && false)) && mv lamclean.old lamclean
dirname: too few arguments
Try `dirname --help' for more information.
mv: cannot stat `lamclean': No such file or directory
make: *** [debian/tmp/usr/bin/lamclean] Error 1

Maintainer cc'd.

xmpi and netpipe still need new uploads once lam is sorted out.  rmpi has
been uploaded, but it looks like it's caught behind r-base.

The hdf5 and mpich portions of the migration look to be in better shape,
although I'm going to take a more detailed look shortly.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> However, there is one catch.  hdf5 also got pulled into this migration
> due to its dependency on the mpich package.  This has already been fixed
> in the version in unstable, but that means that hdf5's dependencies will
> all also have to be ready to go.  That, unfortunately, pulls in a ton of
> other packages.  Here's the full list that have not yet been
> transitioned.

> Source: kmatplot
> Source: plplot
> Source: pytables
> Source: r-cran-hdf5
> Source: semidef-oct
> Source: statdataml
> Source: octave-gpc (contrib)

I have submitted RC bugs against all of these, with the exception of
kmatplot which already has two other RC bugs and isn't in testing.  I'm
making the assumption that by the time kmatplot is ready for testing, it
will have been uploaded again and this problem will already be fixed.

I've also filed an RC bug against lam reporting the FTBFS on m68k and
asking the maintainer to try reducing the optimization level on that
platform.  I took a quick look at the source package and didn't see a
simple way of doing that, so I didn't provide a patch.  If the maintainer
needs help with it, I'll take a closer look.

I have not filed RC bugs on lam's reverse-depends yet, since they
shouldn't be uploaded until lam has been built on all platforms.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Sun, Sep 11, 2005 at 10:34:14PM -0700, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 09, 2005 at 09:23:15PM -0700, Russ Allbery wrote:

> >> It just occurred to me, from following previous transitions... lam also
> >> has not yet been built on m68k.  Does that mean that the above three
> >> source packages should wait on uploading new versions until lam has
> >> been built on all platforms, to make sure that the rebuild gets the
> >> right library version?

> > Yes, unless you set a versioned build dependency, uploading now just
> > means you'll have to do it again later.

> The build of lam has now failed on m68k, which I'm afraid is going to
> impact this transition (not that it's ready to go yet, but this will
> definitely have to be dealt with before it can happen, and before even
> some packages can be built properly, including netpipe).

> devel/lam_7.1.1-3.2: Failed by buildd_m68k-tanda [extra:out-of-date]
>   Reasons for failing:
> [Category: none]
> >  m68k-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../share/include 
> -I../../share/include -DLAM_BUILDING=1 -O3 -pthread -MT ndi_parse.lo -MD -MP 
> -MF .deps/ndi_parse.Tpo -c ndi_parse.c -o ndi_parse.o
> > ndi_parse.c: In function 'ndi_parse1':
> > ndi_parse.c:241: internal compiler error: Segmentation fault
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
> > For Debian GNU/Linux specific bug reporting instructions,
> > see .
> > make[3]: *** [ndi_parse.lo] Error 1

> Not sure whether it would be best to do another upload of lam,
> decreasing optimization for m68k, or if this is an addressable
> toolchain issue.

I'm sure it's addressable, but I don't think there's any sort of ETA yet
for this particular m68k bug.  I think we're much better off getting lam
to use -O2 instead of -O3 here.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Fri, Sep 09, 2005 at 09:23:15PM -0700, Russ Allbery wrote:

>> It just occurred to me, from following previous transitions... lam also
>> has not yet been built on m68k.  Does that mean that the above three
>> source packages should wait on uploading new versions until lam has
>> been built on all platforms, to make sure that the rebuild gets the
>> right library version?

> Yes, unless you set a versioned build dependency, uploading now just
> means you'll have to do it again later.

The build of lam has now failed on m68k, which I'm afraid is going to
impact this transition (not that it's ready to go yet, but this will
definitely have to be dealt with before it can happen, and before even
some packages can be built properly, including netpipe).

devel/lam_7.1.1-3.2: Failed by buildd_m68k-tanda [extra:out-of-date]
  Reasons for failing:
[Category: none]
>  m68k-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../share/include 
-I../../share/include -DLAM_BUILDING=1 -O3 -pthread -MT ndi_parse.lo -MD -MP 
-MF .deps/ndi_parse.Tpo -c ndi_parse.c -o ndi_parse.o
> ndi_parse.c: In function 'ndi_parse1':
> ndi_parse.c:241: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For Debian GNU/Linux specific bug reporting instructions,
> see .
> make[3]: *** [ndi_parse.lo] Error 1

Not sure whether it would be best to do another upload of lam, decreasing
optimization for m68k, or if this is an addressable toolchain issue.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Steve Langasek]

On Fri, Sep 09, 2005 at 09:23:15PM -0700, Russ Allbery wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
> > Source: rmpi
> > Source: xmpi
> > Source: clustalw-mpi (non-free)

> > Thankfully, libxmpi4 doesn't pull in anything else.  I'll add the above
> > packages to the list of ones that need RC bugs filed.

> It just occurred to me, from following previous transitions... lam also
> has not yet been built on m68k.  Does that mean that the above three
> source packages should wait on uploading new versions until lam has been
> built on all platforms, to make sure that the rebuild gets the right
> library version?

Yes, unless you set a versioned build dependency, uploading now just
means you'll have to do it again later.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Steve Langasek]

On Fri, Sep 09, 2005 at 08:53:10PM -0700, Russ Allbery wrote:
> So, I think the next step is to start filing RC bugs against the packages
> depending on the old hdf5 libraries, asking them to rebuild against the
> current ones.

Quite agreed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: mpich C++ transition status

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Also, hdf5 depends on lam, which also had to do its own transition, and
> that adds the following additional packages:

> Package: libxmpi4
> Package: netpipe-lam
> Package: r-cran-rmpi
> Package: xmpi

> netpipe is already implicated in other parts of this transition, so the
> additional source packages are:

> Source: rmpi
> Source: xmpi
> Source: clustalw-mpi (non-free)

> Thankfully, libxmpi4 doesn't pull in anything else.  I'll add the above
> packages to the list of ones that need RC bugs filed.

It just occurred to me, from following previous transitions... lam also
has not yet been built on m68k.  Does that mean that the above three
source packages should wait on uploading new versions until lam has been
built on all platforms, to make sure that the rebuild gets the right
library version?

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mpich C++ transition status

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> However, there is one catch.  hdf5 also got pulled into this migration
> due to its dependency on the mpich package.  This has already been fixed
> in the version in unstable, but that means that hdf5's dependencies will
> all also have to be ready to go.  That, unfortunately, pulls in a ton of
> other packages.

Also, hdf5 depends on lam, which also had to do its own transition, and
that adds the following additional packages:

Package: libxmpi4
Package: netpipe-lam
Package: r-cran-rmpi
Package: xmpi

netpipe is already implicated in other parts of this transition, so the
additional source packages are:

Source: rmpi
Source: xmpi
Source: clustalw-mpi (non-free)

Thankfully, libxmpi4 doesn't pull in anything else.  I'll add the above
packages to the list of ones that need RC bugs filed.

Phew.  I think that's the end of the recursive chain.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mpich C++ transition status

[Russ Allbery]

Sorry about the long period between updates; I caught a cold last weekend
andn that sapped my energy for a while.

Unfortunately, more things are getting caught up in this transition than I
was hoping, not because of the library package changing names, but because
of mpich disappearing and being replaced by mpich-bin.  But that's okay;
we're making progress.

The following are done and ready to migrate with mpich:

Source: blacs-mpi
Source: hdf5
Source: illuminator
Source: mpich
Source: petsc
Source: scalapack
Source: parmetis (non-free)

The following packages still depend on libmpich1.0:

Source: netpipe

The following packages don't depend on the library, but they do depend on
the mpich package which has been removed:

Source: warped

We can safely ignore warped for this purpose, since it's not in testing.
This means that we're down to netpipe which needs a maintainer upload or
NMU.

However, there is one catch.  hdf5 also got pulled into this migration due
to its dependency on the mpich package.  This has already been fixed in
the version in unstable, but that means that hdf5's dependencies will all
also have to be ready to go.  That, unfortunately, pulls in a ton of other
packages.  Here's the full list that have not yet been transitioned.

Package: kmatplot
Package: octave-plplot
Package: octave-sp
Package: octave-statdataml
Package: python2.2-tables
Package: python2.3-tables
Package: python2.4-tables
Package: r-cran-hdf5
Package: octave-gpc (contrib)

This corresponds to the following source packages:

Source: kmatplot
Source: plplot
Source: pytables
Source: r-cran-hdf5
Source: semidef-oct
Source: statdataml
Source: octave-gpc (contrib)

In addition, these:

Source: mpb
Source: tessa

have already been transitioned and are ready to go.

I haven't gone back to look at the build dependencies again yet.  It looks
like just tracking down the dependencies is going to be hard enough, given
that hdf5 is involved.

So, I think the next step is to start filing RC bugs against the packages
depending on the old hdf5 libraries, asking them to rebuild against the
current ones.  The following packages are not in testing, so can be
ignored for the purposes of this transition (although still need RC bugs
filed if they don't already have any):

Source: kmatplot
Source: plplot

The rest are all in testing and will need to migrate at the same time as
mpich and hdf5.  Thankfully, no source changes should be required as near
as I can tell for the hdf5 transition; a new upload to force a rebuild
should be sufficient.

Unless anyone yells that I'm on the wrong track, I'm going to start filing
the above-mentioned RC bugs against the packages depending on the old hdf5
libraries.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]