Description: The LO snap builds from the upstream tarballs. In this case, we're building from (in the snapcraft.yaml): http://download.documentfoundation.org/libreoffice/src/7.2.0/libreoffice-7.2.0.1.tar.xz The snap repo commit being built: https://git.launchpad.net/~hellsworth/+git/libreoffice-snap/commit/?id=d8a871e0d330928885201dcaafdec30dfb0c7b61 The build failure: https://launchpadlibrarian.net/548455036/buildlog_snap_ubuntu_focal_amd64_libreoffice-7.2-wip_BUILDING.txt.gz Locally, I've reproduced this failure and the modules are there, just not in the expected place. snapcraft-libreoffice # find . -name Module_helpcontent2.mk ./parts/libreoffice/build/src/libreoffice-help-7.2.0.1/helpcontent2/Module_helpcontent2.mk Looking through the libreoffice source changes, I believe this commit is the culprit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f3b7dc649bc384be6000d98a87763cab26fe3f32 Reverting this commit in a patch gets past the issue and the build resumes. The corresponding Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1936254 Steps to Reproduce: Try to build from the tarball Actual Results: The build fails due to linking of the help modules. Expected Results: The build should find the modules. Reproducible: Always User Profile Reset: No Additional Info: Reverting this commit fixes the issue: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f3b7dc649bc384be6000d98a87763cab26fe3f32
This issue isn't happening on macOS (old Bash) or the LibreOffice build bots. They may not be using this file Module_helpcontent2.mk. I do not know if this would be helpful, but do you know which shell the build system is using? Either the find command is not finding the file or it is failing silently, or ln -sf is failing silently. Could you try putting set -xv at the top of bin/unpack-sources and getting the output?
Thanks so much Andrew for your help. The build system is using shell, not bash. Also it's the find command that is failing. Currently I'm tinkering with what the find should be, rather than just reverting the commit.
Probably this should be discussed on the developer mailing list