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

[James Addison]

On Mon, 19 Aug 2024 at 15:16, James Addison <jay at jp-hosting.net> wrote:
>
> On Mon, Aug 19, 2024, 13:57 Graham Inggs <ginggs at debian.org> wrote:
>>
>> Hi James
>>
>> On Mon, 19 Aug 2024 at 12:40, James Addison <jay at jp-hosting.net> wrote:
>> > Ok, thank you.  Could we resolve this by adding libelpa.symbols.arch file(s), minus the openmpi symbols, for the failing architectures?
>>
>> That might fix the build, but who will take care of the autopkgtests
>> and reverse-dependencies?
>
>
> From reading one of the linked bug autopkgtest outputs, none of the tests passed at all, and that makes me wonder if they ran despite a faulty binary/program output.
>
> I began attempting a test build locally but on an x86 (64, I'm not completely mad) host under qemu but it was abysmally slow, so I'll try again later on an ARM build host.
>
> From the git history of the symbols file, I also notice that at one point the relevant (open)MPI symbols were tagged as optional.  Perhaps that, even if it is an unusual use of the tag, could allow the build to succeed without creating per-arch files.
>
> In any case: I'll try to provide some results-based feedback soon (next day or so, most likely).

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.

However: I'm not sure that my suggestion to create per-architecture
symbols is ideal.  When trawling through the Debian elpa packaging git
history, I found that the OpenMPI-specific entries were previously
tagged as optional -- and I think that that might be a more convenient
approach.

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

Regards,
James