On Mon, 19 Aug 2024 at 15:16, James Addison <[email protected]> wrote: > > On Mon, Aug 19, 2024, 13:57 Graham Inggs <[email protected]> wrote: >> >> Hi James >> >> On Mon, 19 Aug 2024 at 12:40, James Addison <[email protected]> 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
