[Debichem-devel] Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures

[James Addison]

Thanks Graham!  With an answer to your question inline below:

On Sun, 25 Aug 2024 at 14:02, Graham Inggs <ginggs at debian.org> wrote:
>
> Hi James
>
> On Tue, 20 Aug 2024 at 11:27, James Addison <jay at jp-hosting.net> wrote:
> > Ok: I can confirm that removing the (OpenMPI-provided) symbols from
> > the libelpa19.symbols file resolves the build problem, and that
> > subsequent autopkgtests succeeded on an ARM-based host running when I
> > ran the binary package build locally within a 32-bit ARM container
> > environment.
>
> To be clear, which autopkgtests did you run?  Those of gpaw?
> > I've opened a merge request on Salsa with a possible change to do
> > that: https://salsa.debian.org/debichem-team/elpa/-/merge_requests/1

I only ran the elpa autopkgtests in this case; in hindsight I should have also
confirmed the effect on the dependent package(s).

> Merged, thanks.  Although I do intend to wait for the mpi-defaults
> transition to finish before trying to re-introduce the 32-bit
> binaries.

Thanks again.  I felt that it was worthwhile to offer, but if the resulting
maintenance costs add up in future, please feel free to revert it.

Also, a self-correction in my terminology that I was thinking about earlier in
the week: I don't think I should have said that this was blocking the
transition; it arguably delays completion of the transition, but it didn't
prevent it from progressing.