Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

Control: tags -1 pending

On 07/09/16 10:25, Bas Couwenberg wrote:
> The upload of openmpi (2.0.1-3) to unstable has triggered another
> transition.

This needed a big hammer to get it into testing. The fact that the different
libopenmpi versions conflict with each other doesn't really help.

This is just pending the boost1.58 removal from testing.

Cheers,
Emilio

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

On 25/09/16 12:15, Andreas Beckmann wrote:
> One binNMU is needed for experimental, too:
> 
> nmu hdf5_1.10.0-patch1+docs-1~exp4 . ANY . experimental . -m "Rebuild against 
> libopenmpi2."

Scheduled.

Emilio

Bug#836917: transition: openmpi

[Andreas Beckmann]

One binNMU is needed for experimental, too:

nmu hdf5_1.10.0-patch1+docs-1~exp4 . ANY . experimental . -m "Rebuild against 
libopenmpi2."


Andreas

Bug#836917: transition: openmpi

[Julien Cristau]

On Thu, Sep 15, 2016 at 22:21:19 +0200, Sebastiaan Couwenberg wrote:

> Thanks, that did the trick. Let's hope it doesn't get stuck in Uploaded
> state like pnetcdf (I've already emailed ar...@buildd.debian.org about
> that).
> 
pnetcdf poked to reupload.  Please use debian-wb-team rather than the
arch specific alias, you'll reach more people who can fix that sort of
thing this way.

Cheers,
Julien

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/15/2016 09:41 PM, Emilio Pozuelo Monfort wrote:
> On 15/09/16 21:28, Sebastiaan Couwenberg wrote:
>> On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
>>> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
>>> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
>>> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
>>> 1.10.3, which is now obsolete).
>>
>> I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
>> the timeout has been fixed with the same change in openmpi (2.0.1-5)
>> which solved the timeout for mpi4py.
>>
>> Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
>> was built with -3 which did not contain the wait fix.
> 
> Given back.

Thanks, that did the trick. Let's hope it doesn't get stuck in Uploaded
state like pnetcdf (I've already emailed ar...@buildd.debian.org about
that).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

On 15/09/16 21:28, Sebastiaan Couwenberg wrote:
> On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
>> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
>> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
>> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
>> 1.10.3, which is now obsolete).
> 
> I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
> the timeout has been fixed with the same change in openmpi (2.0.1-5)
> which solved the timeout for mpi4py.
> 
> Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
> was built with -3 which did not contain the wait fix.

Given back.

Emilio

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/12/2016 05:52 PM, Alastair McKinstry wrote:
> mpi4py was also failing to build with openmpi-2.0.1 due to hangs in the
> test suite; I've just uploaded 2.0.1-5 which includes a fix for this.
> mpi4py will need to be rebuilt (there is an older RC bug due to FTBFS on
> 1.10.3, which is now obsolete).

I haven't been able to reproduce the dune-grid FTBFS on powerpc, I think
the timeout has been fixed with the same change in openmpi (2.0.1-5)
which solved the timeout for mpi4py.

Can the dune-grid build be retried on powerpc with openmpi (2.0.1-5)? It
was built with -3 which did not contain the wait fix.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

On 12/09/16 17:52, Alastair McKinstry wrote:
> I've NMU'd libint2 to fix the FTBFS with mpqc3, below. However it takes
> ~6 hours to compile on my decent laptop, and has been failing to build
> on build systems, typically terminating with memory exhaustion.
> 
> What, if anything, can be done to fix this?

RC bug and testing removal.

Cheers,
Emilio

Bug#836917: transition: openmpi

[Kumar Appaiah]

On Fri, Sep 09, 2016 at 05:30:34PM +0200, Sebastiaan Couwenberg wrote:
> On 09/09/2016 05:24 PM, Kumar Appaiah wrote:
> > On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
> >> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  >> l.nl> wrote:
> >> ...
>   
>  It looks like armadillo will require a transition before it will
> >> support
>  superlu >= 5.2.
> >>>  
> >>> To deal with the armadillo/superlu situation, I've disabled armadillo
> >>> support in gdal and will upload a new revision with that change after
> >>> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
> >> be
> >>> fixed in unstable soon.
> >>
> >>
> >> No need to disable gdal. The armadillo upgrade is ready. 
> >>
> >> Kumar, can you upload the new armadillo as soon as possible?  An
> >> accidental openmpi upgrade has complicated everyone's dependencies.
> > 
> > Should I go ahead with the upload or request a transition formally
> > with the release team or go ahead with the upload?
> > 
> > I'll prepare the upload right away but wait for your go ahead.
> 
> As requested in #837152 please coordinate the armadillo transition with
> the Release Team, we've had far too many uncoordinated transition recently.

Sorry, I just uploaded it! I'll e-mail Debian release right away.

Kumar
-- 
Kumar Appaiah

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/09/2016 05:24 PM, Kumar Appaiah wrote:
> On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
>> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg > l.nl> wrote:
>> ...
  
 It looks like armadillo will require a transition before it will
>> support
 superlu >= 5.2.
>>>  
>>> To deal with the armadillo/superlu situation, I've disabled armadillo
>>> support in gdal and will upload a new revision with that change after
>>> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
>> be
>>> fixed in unstable soon.
>>
>>
>> No need to disable gdal. The armadillo upgrade is ready. 
>>
>> Kumar, can you upload the new armadillo as soon as possible?  An
>> accidental openmpi upgrade has complicated everyone's dependencies.
> 
> Should I go ahead with the upload or request a transition formally
> with the release team or go ahead with the upload?
> 
> I'll prepare the upload right away but wait for your go ahead.

As requested in #837152 please coordinate the armadillo transition with
the Release Team, we've had far too many uncoordinated transition recently.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Kumar Appaiah]

On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  l.nl> wrote:
> ...
> > > 
> > > It looks like armadillo will require a transition before it will
> support
> > > superlu >= 5.2.
> > 
> > To deal with the armadillo/superlu situation, I've disabled armadillo
> > support in gdal and will upload a new revision with that change after
> > 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
> be
> > fixed in unstable soon.
> 
> 
> No need to disable gdal. The armadillo upgrade is ready. 
> 
> Kumar, can you upload the new armadillo as soon as possible?  An
> accidental openmpi upgrade has complicated everyone's dependencies.

Should I go ahead with the upload or request a transition formally
with the release team or go ahead with the upload?

I'll prepare the upload right away but wait for your go ahead.

Thanks.

Kumar
-- 
Kumar Appaiah

Bug#836917: transition: openmpi

[Drew Parsons]

On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  wrote:
...
> > 
> > It looks like armadillo will require a transition before it will
support
> > superlu >= 5.2.
> 
> To deal with the armadillo/superlu situation, I've disabled armadillo
> support in gdal and will upload a new revision with that change after
> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
be
> fixed in unstable soon.


No need to disable gdal. The armadillo upgrade is ready. 

Kumar, can you upload the new armadillo as soon as possible?  An
accidental openmpi upgrade has complicated everyone's dependencies.

Drew

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/09/2016 11:25 AM, Sebastiaan Couwenberg wrote:
> On 09/08/2016 01:07 PM, Sebastiaan Couwenberg wrote:
>> I've done a round of rebuilds to assess the impact of this transition.
>> The results are summarized below. Several package suffer from
>> uninstallable build dependencies by having libopenmpi1.10 pulled in by
>> dependencies that failed to rebuild.
> 
> Quite a few packages require vtk6 to be rebuilt before their
> dependencies can be satisfied.
> 
> Unfortunately vtk6 has a large dependency chain, which is prone to issues.
> 
> mpi4py is one of the vtk6 build dependencies that needs to be fixed
> (#830440).
> 
> Another is the recent update of superlu in unstable which has made the
> armadillo packages and their reverse dependencies uninstallable
> (#837152). This includes gdal and by extension vtk6.
> 
> It looks like armadillo will require a transition before it will support
> superlu >= 5.2.

To deal with the armadillo/superlu situation, I've disabled armadillo
support in gdal and will upload a new revision with that change after
2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't be
fixed in unstable soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/08/2016 01:07 PM, Sebastiaan Couwenberg wrote:
> I've done a round of rebuilds to assess the impact of this transition.
> The results are summarized below. Several package suffer from
> uninstallable build dependencies by having libopenmpi1.10 pulled in by
> dependencies that failed to rebuild.

Quite a few packages require vtk6 to be rebuilt before their
dependencies can be satisfied.

Unfortunately vtk6 has a large dependency chain, which is prone to issues.

mpi4py is one of the vtk6 build dependencies that needs to be fixed
(#830440).

Another is the recent update of superlu in unstable which has made the
armadillo packages and their reverse dependencies uninstallable
(#837152). This includes gdal and by extension vtk6.

It looks like armadillo will require a transition before it will support
superlu >= 5.2.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Alastair McKinstry]

On 08/09/2016 12:07, Sebastiaan Couwenberg wrote:
> I've done a round of rebuilds to assess the impact of this transition.
> The results are summarized below. Several package suffer from
> uninstallable build dependencies by having libopenmpi1.10 pulled in by
> dependencies that failed to rebuild.
>
>
> scalapack (1.8.0-12.3) FTBFS due to undefined references to MPI symbols.
>
> Bugreports for the above will be filed soon.
>
>
> Transition: openmpi
>
>  libopenmpi1.10 (1.10.3-3) -> libopenmpi2 (2.0.1-3)
>
> The status of the most recent rebuilds is as follows.
>
>  aces3 (sid only)   (3.0.8-5) FTBFS (#831164)
This is a FTBFS due to a library libgfortranbegin.a that appears dropped
in gfortran-6.
I'm uploading a patch today.

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#836917: transition: openmpi

[Alastair McKinstry]

Dear Bas,

I sincerely apologise for the upload 2.0.1-3. It was meant to be  an
upload to  'experimental', not to 'sid', to avoid the transition.

Kind regards
Alastair

On 07/09/2016 09:25, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-openmpi.html
>
> It sadly seems to be the season of uncoordinated transitions, with some
> maintainers not learning for their past mistakes. Very disappointing.
>
> The upload of openmpi (2.0.1-3) to unstable has triggered another
> transition. Because of the large number of affected packages, you
> (OpenMPI Maintainers) really should have waited for an ACK from the
> Release Team. Please imprint the transition documentation in your mind
>
>  https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> And most importantly, adhere to the workflow whenever library package
> are renamed for SONAME bumps! OpenMPI 2.0 should have stayed in
> experimental until the Release Team was ready for the transition.
>
> Kind Regards,
>
> Bas (an unhappy maintainer of affected packages)
>

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

I've done a round of rebuilds to assess the impact of this transition.
The results are summarized below. Several package suffer from
uninstallable build dependencies by having libopenmpi1.10 pulled in by
dependencies that failed to rebuild.

fftw (2.1.5-4) FTBFS due to . being removed from @INC in recent perl.

The gmsh (2.13.2+dfsg1-1) dependencies could initially not be installed
because hdf5 was still pulling in libopenmpi1.10 which conflicts with
libopenmpi2. The ben dependency levels did not reflect that. With the
rebuilt hdf5 the gmsh rebuild succeeded.

The molds (0.3.1-1) had a similar issue due to boost pulling in the old
libopenmpi1.10. With the rebuilt boost the molds rebuild succeeded too.

p4est (1.1-2) FTBFS due to test failures.

tachyon (0.99~b6+dsx-5) FTBFS due to: undefined reference to symbol
'XNextEvent'

abyss (1.9.0-1) FTBFS due to: db-csv.cc:23:9: error: cannot convert
'std::ifstream {aka std::basic_ifstream}' to 'bool' in return

gromacs (2016-2) FTBFS due to test failures.

scalapack (1.8.0-12.3) FTBFS due to undefined references to MPI symbols.

Bugreports for the above will be filed soon.


Transition: openmpi

 libopenmpi1.10 (1.10.3-3) -> libopenmpi2 (2.0.1-3)

The status of the most recent rebuilds is as follows.

 aces3 (sid only)   (3.0.8-5) FTBFS (#831164)
 arpack (3.4.0-1) OK
 blacs-mpi  (1.1-37)  OK
 boost1.58  (1.58.0+dfsg-5.1) FTBFS (#811651)
 boost1.61  (1.61.0+dfsg-2.1) OK
 cctools (sid only) (4.0-1)   OK
 dune-grid  (2.4.1-1) OK
 fftw   (2.1.5-4) FTBFS
 fftw3  (3.3.4-2) OK
 gerris (20131206+dfsg-9) OK
 gmsh   (2.13.2+dfsg1-1)  OK
 gpaw   (1.1.0-1) OK
 hdf5   (1.8.16+docs-8)   OK
 hpcc   (1.4.3-1) OK
 hyphy  (2.2.6+dfsg-5)OK
 hypre  (2.8.0b-3)OK
 molds  (0.3.1-1) OK
 mpi4py (2.0.0-2) OK
 mpqc (sid only)(2.3.1-16.1)  FTBFS (#812036)
 mpqc3  (0.0~git20160216-3)   OK
 mrbayes(3.2.6+dfsg-1)OK
 mrmpi  (1.0~20140404-1)  OK
 octave-mpi (1.2.0-2) OK
 open-coarrays  (1.7.0-1) OK
 otf(1.12.5+dfsg-2)   OK
 p4est  (1.1-2)   FTBFS
 palabos(1.5~r1+repack1-2)OK
 parmetis   (4.0.3-4) OK
 pnetcdf(1.7.0-1) OK
 ray(2.3.1-4) OK
 regina-normal  (4.96-4)  OK
 rmpi   (0.6-6-1) OK
 ruby-mpi   (0.3.0-1) OK
 scotch (5.1.12b.dfsg-2)  OK
 spooles(2.2-12)  OK
 tachyon(0.99~b6+dsx-5)   FTBFS
 valgrind   (1:3.12.0~svn20160714-1)  OK

 abyss  (1.9.0-1) FTBFS
 adios  (1.9.0-12)BD-UNINST
 ampliconnoise  (1.29-5)  OK
 code-saturne   (4.2.1+repack-1)  OK
 elkcode (sid only) (2.3.22-1)FTBFS (#825934)
 ffindex(0.9.9.7-1)   OK
 gfsview(20121130+dfsg-2) OK
 gromacs(2016-2)  FTBFS
 lammps (0~20151117.gite3c4db7-3) OK
 libghemical (sid only) (3.0.0-4.1)   BD-UNINST
 libgpiv(0.6.1-4.3)   OK
 mathgl (2.3.4-1) FTBFS (#835680)
 meep-mpi-default   (1.3-3)   OK
 meep-openmpi   (1.3-3)   OK
 mpb(1.5-2)   OK
 murasaki   (1.68.6-6)OK
 music (sid only)   (1.0.7-1.2)   FTBFS (#811907)
 netpipe(3.7.2-7.4)   OK
 ns3(3.25+dfsg2-3)OK
 openmx (3.7.6-1) OK
 paraview   (5.1.2+dfsg1-1)   BD-UNINST
 phyml  (3:3.2.0+dfsg-2)  OK
 prime-phylo(1.0.11-4)OK
 python-escript (4.2.0.1-4)   OK
 relion (1.4+dfsg-2)  OK
 scalapack  (1.8.0-12.3)  FTBFS
 silo-llnl  (4.10.2-6)OK
 starpu (1.1.4+dfsg-6)OK
 starpu-contrib (1.1.4+dfsg-6)OK
 tessa (sid only)   (0.3.1-6.1)   FTBFS (#817690)
 tree-puzzle(5.2-8)   OK

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/08/2016 12:00 AM, Emilio Pozuelo Monfort wrote:
> On 07/09/16 10:25, Bas Couwenberg wrote:
>> It sadly seems to be the season of uncoordinated transitions, with some
>> maintainers not learning for their past mistakes. Very disappointing.
> 
> It's already started, so let's tag it as such.
> 
> I have urgented proj so that e.g. vtk6 can migrate and doesn't get tangled 
> with
> this transition.

Many thanks for that!

I'm about halfway through the rebuilds of the openmpi rdeps, I should
have the results of that sometime tomorrow.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/09/16 10:25, Bas Couwenberg wrote:
> It sadly seems to be the season of uncoordinated transitions, with some
> maintainers not learning for their past mistakes. Very disappointing.

It's already started, so let's tag it as such.

I have urgented proj so that e.g. vtk6 can migrate and doesn't get tangled with
this transition.

Cheers,
Emilio

Bug#836917: transition: openmpi

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-openmpi.html

It sadly seems to be the season of uncoordinated transitions, with some
maintainers not learning for their past mistakes. Very disappointing.

The upload of openmpi (2.0.1-3) to unstable has triggered another
transition. Because of the large number of affected packages, you
(OpenMPI Maintainers) really should have waited for an ACK from the
Release Team. Please imprint the transition documentation in your mind

 https://wiki.debian.org/Teams/ReleaseTeam/Transitions

And most importantly, adhere to the workflow whenever library package
are renamed for SONAME bumps! OpenMPI 2.0 should have stayed in
experimental until the Release Team was ready for the transition.

Kind Regards,

Bas (an unhappy maintainer of affected packages)