On 2019-01-16 15:28, Alastair McKinstry wrote:
> Matching changes should probably be made for mpich, the other mpi
> alternative.
Done, pushed to branch anbe/alternatives
This time, not even build-tested :-)
I also added the Breaks against the versions predating mpi-$MULTIARCH
including the
On 16/01/2019 14:01, Alastair McKinstry wrote:
On 16/01/2019 13:49, Andreas Beckmann wrote:
On 2019-01-16 13:58, Alastair McKinstry wrote:
Hi
Would you happen to know syntax for piuparts to enable an upgrade test
from stretch to a new (local) version?
the command line for the normal
On 2019-01-16 15:28, Alastair McKinstry wrote:
> Matching changes should probably be made for mpich, the other mpi
> alternative.
looks quite straight-forward, I'll take a look.
I think both mpich,libmpich-dev and openmpi-bin,libopenmpi-dev should
have versioned Breaks against each other to
On 2019-01-16 15:01, Alastair McKinstry wrote:
>> Once we have reached a clean state (with 3.1.3-10 installed), there
>> should be no need to rerun the preinst cleanup operations for every
>> subsequent upgrade?
>
> Unfortunately, experience is that we'll see people upgrading from random
> old
On 16/01/2019 13:49, Andreas Beckmann wrote:
On 2019-01-16 13:58, Alastair McKinstry wrote:
Hi
Would you happen to know syntax for piuparts to enable an upgrade test
from stretch to a new (local) version?
the command line for the normal stretch2{buster,sid} test can be derived
from
Followup-For: Bug #915025
Control: found -1 3.1.3-9
Preparing to unpack .../45-libopenmpi-dev_3.1.3-9_amd64.deb ...
dpkg: error processing archive
/tmp/apt-dpkg-install-bUBTzo/45-libopenmpi-dev_3.1.3-9_amd64.deb (--unpack):
new libopenmpi-dev package pre-installation script subprocess
Package: libopenmpi-dev
Version: 3.1.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.
>From the attached log
7 matches
Mail list logo