Bug#1133815: libgmm-dev fails to coinstall

[Helmut Grohne]

Control: unblock -1 by 1134834
Control: unblock -1 by 1135069
Control: severity -1 serious

Hi Graham,

On Mon, Jun 15, 2026 at 11:12:15AM +0000, Graham Inggs wrote:
> On Fri, 24 Apr 2026 14:58:06, Drew Parsons <dparsons at debian.org> wrote:
> > The mumps build failure is in the nonofficial arches
> > hppa and powerpc, so broken support for them can't be considered
> > a RC bug.  Hence reducing the severity of this bug to normal.
> 
> I don't think this bug is related to build failures on non-release
> architectures.

I concur. This bug is not about powerpc or hppa. Hence removing the
block relations.

> I compared some of the libgmm-dev binary packages and found the
> following difference:
> 
> $ diffoscope  libgmm-dev_5.5+dfsg1-1_amd64.deb libgmm-dev_5.5+dfsg1-1_s390x.deb
> 
> │ │ ├── ./usr/include/gmm/gmm_arch_config.h
> │ │ │ @@ -25,11 +25,11 @@
> │ │ │  /* defined if superlu header files are not under a subdirectory
> called "superlu" */
> │ │ │  /* #undef GMM_NO_SUPERLU_INCLUDE_SUBDIR */
> │ │ │
> │ │ │  /* Use blas with 64 bits integers */
> │ │ │  /* #undef GMM_USE_BLAS64_INTERFACE */
> │ │ │
> │ │ │  /* defined if the BLAS fortran ABI does not return complex
> values directly (e.g. Intel's MKL) */
> │ │ │ -/* #undef GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT */
> │ │ │ +#define GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT /**/
> │ │ │
> │ │ │  /* GMM version */
> │ │ │  #define GMM_VERSION "5.5"

I concur. Therefore libgmm-dev violates current Debian policy on a
release architecture. The appropriate severity is serious.

> One solution is to simply drop the Multi-Arch: same field from the
> libgmm-dev binary package (only).  See a similar bug reported against
> libtrilinos-kokkos-kernels-dev  [1].

Yes. Droping M-A:same is a sensible resolution of this bug. It is a
small minority of lib*-dev packages that need to be M-A:same and I doubt
this to be needed for libgmm-dev. If there is such a need, more effort
can be invested into the header.

Helmut