Lmms: Incomplete source tarball for 1.2.0 RC5 -> build error in src/3rdparty/qt5-x11embed

[GvMariani]

Trying to package lmms 1.2.0 RC5 for Rosa Linux Fresh R10 (a Mandriva derivative) on x86_64.
Cmake stops with the error message:

---

CMake Error at src/3rdparty/CMakeLists.txt:6 (add_subdirectory):
The source directory /tmp/abf/rpmbuild/BUILD/lmms-1.2.0-rc5/src/3rdparty/qt5-x11embed
does not contain a CMakeLists.txt file.

---

Attached the full log
BuildFailure.txt

Indeed the directory src/3rdparty/qt5-x11embed is empty in the RC5 tarball, while it is absent in the RC4 one (and using it produces a successful build).
So I guess you will need to regenerate the source tarball for 1.2.0 RC5...

[tresf]

@GvMariani you'll need to fetch the submodules. git submodule update --init --recursive

[lukas-w]

@GvMariani We don't provide any source tarballs, these are generated by GitHub. Currently, the only way to get the complete source is by using git:

git clone --recursive https://github.com/LMMS/lmms.git
git checkout v1.2.0-rc5

Or if you already cloned the repository using git but without submodules:

git submodule update --init --recursive

[tresf]

@lukas-w this may be something worth uploading at release time. Here's a helper script that claims to tackle it. https://github.com/meitar/git-archive-all.sh/blob/master/git-archive-all.sh

[lukas-w]

Agreed. Thanks for sharing.

[PhysSong]

@GvMariani You mean the tarball in our release page?

[GvMariani]

@PhysSong Exactly...
The usual workflow when updating a distro package (at least for a rpm-based distro, the compile-for-source ones are another matter) is taking the release tarball for the chosen release and using it, not starting by cloning the whole git devel tree (no matter how easy this would be)... But if cloning is needed this would not a big deal for me, anyway.
My point (i.e. what I would like to point our in this bug) are that an "official" source tarball as-is does not work, because it lacks something that is needed to build the project (IMHO a source tarball provided in the release page of a project naturally qualifies itself as "official"...), and that there is no clear warning about this: so someone other than me could really fall in the same trap...

So, if really there is no way to have a complete source tarball for lmms at hand, I think that, at least, there is the need of a prominent warning in the release page against using the tarball provided here and a link to the Wiki instructions about compiling lmms by cloning the git tree (perhaps with the aid of the above useful script from tresf...).

[tresf]

there is the need of a prominent warning in the release page against using the tarball provided here

We won't be doing this. We aren't going to put warnings on all of our releases.

So, if really there is no way to have a complete source tarball for lmms at hand

There is, we just need to integrate it with our release cycle. Thanks for the bug report. Please see https://github.com/LMMS/lmms/issues/4100#issuecomment-356071148 for how we plan to do this. This means future releases (hopefully 1.2.0-stable and onward) will have all submodules bundled as you've requested.

[Polynomial-C]

Just a reminder that this needs to be fixed.
We at Gentoo still ship version 1.2.0_rc4 because all newer tarballs are incomplete and cannot be used to build lmms. Pulling some git sources to make a source tarball actually useful is completely against the intention behind source tarballs.

[tresf]

We've already acknowledged the problem and we've identified some basic steps to make it happen. When this is automated, it'll happen automatically and we welcome help on that front. Until then, the package is going to be incomplete and we need help, not complaints.

I'll self-assign and milestone for 1.3.0 but I'd happily accept help from others before then. What we need is a post-build step for tagged release uploads a build artifact with all submodules, but with the .git directories stripped out.

We could chain this into the default Linux build or we could make a dedicated build target for it.

[jasp00]

Debian integration should produce a tar.xz. However, it only matters if third-party modules are not packaged separately.